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ALUOS  EXECUTIVE  SUMMARY 


In  February,  1978,  a  program  to  develop  an  Automated  ^ow-Cost  Weather 
Observation  System  (ALWOS)  was  initiated  un?er  Interagency  Agreement 
?0T-FA73WAI  Fetween  the  National  Weather  Service  (NWS)  and  the  Federal 
Aviation  Administration  (FAA).  The  applicable  engineering  requirement 
(FAA-ER-ASl-lSS,  dated  February  13,  1978)  specified  the  work  required 
for  the  design,  fabrication,  test  and  evaluation  of  an  ALWOS. 

This  program  Is  part  of  an  on-going  automation  effort  by  both  the  FAA 
and  NWS  and  builds  on  the  knowledge  and  experience  gained  from  earlier 
automation  programs  such  as  AV-AWOS  (Aviation  -  Automated  Weather 
Observation  System),  AUTOB  (Automatic  Observing  Station)  and  WAVE 
(Winds,  Altimeter  and  Voice  Equipment). 

One  of  the  primary  objectives  of  this  program  was  to  design  a 
developmental  model  ALWOS  for  the  lowest  possible  cost.  Reliability 
and  maintenance  costs  over  the  life  of  the  system  were  considered  In 
addition  to  the  Initial  purchase  and  Installation  costs.  To  this  end, 
field  proven,  off  the  shelf  components  were  used  wherever  possible 
throughout  the  system. 

Another  primary  objective  was  modularity  of  design.  The  hardware  and 
software  were  constructed  to  allow  flexibility  In  interfacing  a 
variety  of  sensors  or  adding  additional  sensors  to  measure  new 
parameters . 


The  ALWOS  system  was  Installed  at  t1i«-04*4les  international  Airport, 
near  Washington  O.C.,  for  evaluation.  The  weather  parameters  observed 
included:  sky  conditlon/cloud  height,  visibility,  temperature,  dew 
point,  wind  speed/direction,  altimeter  setting,  precipitation 
occurrence,  and  thunderstorm  (lightning)  occurrence.  Output  from 
ALWOS  was  collected  and  compared  with  official  weather  observations 
taken  by  personnel  from  the  collocated  National  Weather  Service  Office 
(WSO).  Installation  and  maintenance  of  the  system  and  sensors  was 
provided  by  the  NWS  Integrated  Systems  Laboratory  (ISL).  Data 
collection  and  analysis  were  performed  by  members  of  the  NWS  Test  and 
Evaluation  Division  (TsEO),  whose  offices  are  located  adjacent  to 
Dulles  Airport.  The  field  evaluation  lasted  for  six  months,  12  March 
through  15  September  1981.  ALWOS  was  not  used  operationally  during 
the  field  evaluation  period. 

8ased  upon  the  field  evaluation  of  the  ALWOS  system,  the  following 
points  should  be  emphasized: 

a.  The  ALWOS  as  configured  at  Dulles  Airport  is  a  low-cost  and 
flexible  system  which  can  provide  an  automatic  weather 
observation  from  the  data  acquisition,  processing  and 
display  point  of  view,  with  the  potential  for  good 
long-term  system  reliability.  After  a  period  of 
familiarization  with  the  equipment  and  dealing  with  an 
assortment  of  system  and  sensor  problems,  the  functioning 
of  the  system  became  relatively  trouble-free. 
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b.  Evaluation  of  the  ALWOS  supports  the  generally 
accepted  concept  that  automated,  low-cost  weather 
observation  systems  can  Indeed  perform  such  a  function 
given  suitable  sensing  devices. 

c.  Performance  of  some  of  the  various  ALWOS  sensors 
reinforces  the  Important  and  still  basically  unfulfilled 
need  for  suitable  instruments  which  can  supply  informa¬ 
tion  that  can  be  successfully  incorporated  into  an 
automated  observing  scheme.  This  is  particularly  true 
for  cloud,  visibility,  and  thunderstorm  detection  data. 

The  selected  ALWOS  ceilometer  was  unacceptable 

due  to  its  consistently  large  output  of  missing  data. 

The  visibility  sensor  may  have  suffered  from  a  period  of 
serious  unreliability  (which  eventually  required 
replacement  of  the  sensor).  The  selected  ALWOS 
lightning  detector  as  designed  was  unsuitable  for  human 
vs.  machine  comparisons  and  also  displayed  a  high  false 
alarm  rate,  at  least  during  the  early  months  of  the 
evaluation. 

d.  Temperature,  wind  direction/speed,  and  altimeter  setting 
observations  generally  compared  favorably  with  the  human 
observer.  When  the  sensor  was  operating  properly,  dew 
point  temperatures  also  compared  favorably.  Precipitation 
Yes/No  was  handled  reasonably  well  by  the  selected  ALWOS 
sensor.  With  proper  sensor  operation,  reported 

ALWOS  visibilities  showed  reasonable  agreement  with  the 
human  observer  in  many  instances,  but  sensor  location 
introduced  a  source  of  significant  disagreement  under 
certain  visibility  conditions. 

e.  It  was  not  within  the  scope  of  the  evaluation  effort  to 
thoroughly  review  the  performance  of  the  parameter 
algorithms.  Algorithms  were  examined  to  the  extent  where 
discrepant  ALWOS  observations,  inconsistencies  in 
reporting,  etc.,  were  determined  to  be  caused  by  the 
algorithms  themselves  or  the  manner  in  which  the  algorithms 
were  programmed  into  the  system. 


1.0  INTRODUCTION 


ALWOS*  is  an  acronym  for  Automated  Low-cost  Weather  Observation  System. 
The  program  is  funded  by  the  Federal  Aviation  AdminTstration  (FITa)  and 
developed  by  the  National  Weather  Service  (NWS).  The  system,  as 
tested,  consists  of  a  fully  automated  microcomputer  system  with 
sensors  to  measure  cloud  height  and  coverage,  visibility,  temperature, 
dew  point,  wind  speed  and  direction,  station  pressure  /  altimeter 
setting,  precipitation  and  thunderstorm  occurrence  with  the  capability 
to  add  other  parameters  as  needed.  Outputs  from  the  system  include: 
local  and  remote  displays,  local  magnetic  tape  archive,  local 
printout,  remote  telephone  dial-up,  as  well  as  computerized  voice 
output.  FAA's  need  for  an  ALWOS-type  system  is  for  the  more  than  400 
general  aviation  airports  where  little  or  no  weather  observations  are 
currently  taken.  With  an  automated  system  installed  at  these 
airports,  more  of  the  general  aviation  needs  could  be  served  including 
air  taxi  or  commuter  traffic  which  require  that  weather  observations 
be  taken. 

Tests  performed  on  earlier  NWS  automated  weather  systems  such  as 
AV-AWOS  (Aviation  Automated  Weather  Observation  System)  and  AUTOB 
(Automatic  Observation  -  Clouds  and  Visibility)  were  used  as  a  basis 
for  the  software  algorithms  and  hardware  configurations  that  were  used 
in  ALWOS.  An  important  result  from  the  AV-AWOS^  test  was  that  a 
single  sensor  could  be  used  with  a  time  averaging  algorithm  to  measure 
cloud  height/coverage  and  a  single  sensor  for  visibility  at  most 
airports.  This  result  is  important  because  today  the  cost  of  sensors 
to  measure  these  two  parameters  far  exceeds  the  combined  costs  of  the 
processing  equipment  and  the  remaining  complement  of  sensors. 
Otherwise,  a  relatively  low  cost  automated  weather  observation  system 
would  not  be  feasible. 

The  purpose  of  the  ALWOS  test  is  to  evaluate  the  overall  system 
performance  including  processors,  sensors,  field  electronics,  system 
output  peripherals  an  sensor  processing  algorithms.  The  results  of 
the  six  month  test  at  Dulles  Airport  are  presented  in  this  report  as 
well  as  applicable  hardware/software  documentation.  Software  listings 
and  other  detailed  hardware/software  documentation  are  provided 
separate  from  this  document. 


^  Aviation  Au  omated  Weather  Observation  System  (AV-AWOS),  Mar. ,1979, 
Report  No.  FAA-RD-79-63. 


2.  Hardware  Configuration 


The  ALWOS  hardware  configuration  consists  of  four  major  functional 
components:  sensors,  remote  analog  to  digital  conversion  system,  data 
processing  equipment,  and  system  output  peripherals  (figure  2-1).  Its 
basic  functional  design  is  similar  to  the  AV>AW0S  configuration  In 
that  cloud  coverage  and  visibility  data  have  been  automated,  remote 
analog  sensor  data  Is  digitized  before  being  sent  to  the  main 
processor,  and  a  processed  weather  observation  has  been  assembled, 
formatted  and  sent  to  a  variety  of  output  peripherals  as  often  as  once 
per  minute.  The  major  differences  between  ALWOS  and  AV-AUOS  are  that 
the  ALWOS  system  uses  a  single  sensor  to  determine  cloud  height  and 
coverage  and  a  single  sensor  for  visibility  (AV-AWOS  used  3  sensors 
for  each),  and  that  a  relatively  small  microcomputer  system  rather 
than  a  large  minicomputer  system  performs  all  the  data  processing 
functions.  However,  ALWOS  offers  the  advantages  of  lower  cost  due  to 
Its  use  of  single  sensor  clouds  and  visibility  processing  and  higher 
reliability  since  its  entire  software  program  Is  stored  In  solid  state 
memory  rather  than  electromechanical  disk  storage  used  with  the 
AV'AWOS  system.  The  ALWOS  system  was  configured  In  a  modular  design 
that  allows  easy  modifications  or  expansion  and  to  Include  as  many 
quality  control  and  self-check  features  as  possible.  Each  of  the  four 
major  functional  components  of  the  ALWOS  system  as  well  as  a  cost 
analysis  Is  discussed  In  the  following  sections. 


BLOCK  DIAGRAM  OF  THE  AUTOMATIC 
LOW-COST  WEATHER  OBSERVATION  SYSTEM  (ALWOS) 


FIG.  2-1 
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2.1  Sensors 


2.1.1  Ceilometer 

^  pi^ototype  Gallium  Arsenide  (GaAs)  laser  ceilometer,  built  by 
IMPUlSf^HYSiK  of  West  Germany,  is  used  to  measure  cloud  height/coverage 
for  the  six-month  ALWOS  test.  This  sensor  was  selected  as  the  result 
of  an  RFP  for  the  procurement  of  a  laser  ceilometer,  released  in 
February,  1978.  The  need  for  such  a  ceilometer  is  apparent  when 
compared  to  the  widely  used,  but  aging,  Rotating  Beam  ^eilometer 
(RBC).  It  offers  the  advantages  of  minimal  sensor  installation  area 
since  transmitter  and  receiver  are  co-located,  in  addition  to 
increased  reliability  due  to  its  solid  state  design  as  opposed  to  the 
rotating  mechanical  components  used  in  the  RBC. 

The  unit  measures  cloud  height  by  transmitting  low  energy  light  pulses 
and  measuring  the  time  required  for  the  light  to  be  reflected  off  a 
cloud  base  and  back  into  the  receiver  unit.  Due  to  the  extremely  weak 
signal  returns  normally  found  in  this  mode  of  operation,  several  of 
the  p  Ise  returns  are  summed  together  to  detect  the  presence  of  a 
cloud  over  a  given  height  range  or  bin.  Internal  timing  circuitry 
then  slides  the  signal  summing  function  in  time  to  measure  another 
height  range  or  bin  and  continues  this  operation  until  the  entire  3000 
foot  range  is  covered. 

Its  performance  characteristics  include  providing  cloud  data  at 
heights  between  100  and  3100  feet  with  a  range  resoli^tion  of  50  feet, 
cycling  through  a  complete  range  scan  at  least  every  30  seconds,  and 
designed  to  be  "eye  safe"  when  the  human  eye  is  exposed  to  the  beam. 

The  unit  is  also  capable  of  measuring  its  own  receiver  sensitivity  and 
transmitted  laser  power  and  sending  this  information  along  with  the 
cloud  data  to  a  remote  processor.  Data  is  transmitted  asynchronously 
in  a  serial  bit  format  at  110  baud  using  an  EIA  RS-232  voltage 
interface.  Each  character  transmitted  contains  1  start,  2  stop,  1  odd 
parit. .  and  8  data  bits.  The  65  character  data  stream  is  transmitted 
for  every  range  scan  of  the  ceilometer,  nominally  every  28  seconds, 
and  takes  approximately  7  seconds  to  complete  its  message.  An  ASCII 
"STX"  character  begins  the  message  followed  by  a  receiver  sensitivity 
character  and  a  transmitted  output  power  character.  Characters  4 
through  64  represent  the  backscattered  energy  measured  in  each  of  the 
50  foot  range  bins  from  100  to  3100  feet.  The  amount  of  energy 
detected  is  coded  in  binary  where  all  zeroes  represent  the  least 
amount  of  backscattered  energy  and  all  ones  represent  the  most. 

Character  65  is  an  ASCII  "EOT"  representing  the  end  of  the  message. 

Although  new  cloud  range  scan  data  is  transmitted  by  the  ceilometer  ^  s 

every  28  seconds,  the  ALWOS  cloud  algorithm  processes  a  running  25 

minute  (approx.)  average  and  outputs  a  new  cloud  height/coverage 

message  every  4  minutes  (approx.).  At  initial  system  start-up,  no 

message  is  available  until  the  25  minute  buffer  is  filled.  A 

photograph  of  the  ceilometer  is  shown  in  figure  2-2.  (For  a  more 

complete  discussion  of  the  ceilometer's  technical  details,  refer  to 

the  IMPULSPHYSIK  LASER  CEILOGRAPH  LD-WHL  MANUAL) 

2.1.2  Visibility 

The  EG&G  model  207  forward  scatter  meter  (rigure  2-3)  was  selected  by 
NWS  to  measure  visibility  for  the  ALWOS  system  test.  A  forward 
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IMPULSPHYSIK  Laser  Ceilometer 
Figure  2-2 


scatter  visibility  sensor  was  favored  over  the  backscatter  type 
because  of  the  former's  inherent  ability  to  more  closely  follow  the 
theoretical  relationship  to  total  scattering  coeff icient2.  This 
comparison  is  based  on  typical  scattering  angles  of  30  degrees  for  the 
forward  scatter  instrument  versus  180  degrees  for  the  backscatter 
sensor.  In  addition,  the  relative  signal  return  levels  are  larger  in 
the  forward  scatter  instrument  than  in  the  backscatter  type  thus 
making  the  signal  processing  task  somewhat  easier.  This  particular 
instrument  was  selected  based  on  the  extensive  testing  performed  by 
the  Air  Force  and  the  reported  low  failure  rates  and  simplicity  of 
design.  Field  calibration  of  the  unit  is  also  possible  through  the 
use  of  a  special  apparatus  that  provides  a  standardized  scattering 
med i urn. 

The  unit  measures  the  atmospheric  forward  scattering  coefficient  in 
the  20  to  50  degree  range.  It  consists  of  a  light  source  and  detector 
separated  by  approximately  four  feet  (figure  2-4).  Light  from  the 
source  is  projected  in  a  cone-shaped  beam  over  the  angle  of  20  to  50 
degrees  from  the  center  axis  toward  the  detector.  The  detector  looks 
toward  the  light  source  and  is  optically  configured  to  respond  to 
light  received  in  a  similarly  shaped  volume.  The  intersection  of 
these  two  optical  alignments  is  a  toroidal  shaped  volume  approximately 
2  feet  in  d i ameter  and  two  feet  thick.  Optical  scattering  of  the 
transmitted  light  into  the  receiver  unit  is  a  function  of  the  aerosols 
contained  in  the  sampling  volume  and,  in  the  absence  of  absorption, 
determine  the  atmospheric  extinction  coefficient  or  visual  range. 
Basically,  the  more  light  scattered  into  the  detector,  the  lower  the 
visibility  and  vice  versa.  Modulation  of  the  light  source  and 
synchronous  detection  of  the  scattered  light  are  done  to  eliminate 
interference  from  extraneous  light  sources. 

Linear  and  positive  logarithmic  voltage  outputs  are  available  from  the 
Model  207  and  represent  visibilities  from  200  to  20,000  feet.  An 
optional  negative  logarithmic  output,  installed  in  our  test  units, 
provides  signal  voltages  for  visibilities  greater  than  20,000  feet. 
However,  the  processing  algorithm  limits  the  upper  range  of  reported 
visibilities  to  8  miles.  The  internal  electronics  of  the  sensor  are 
configured  such  that  as  the  visibility  increases  from  200  to  20,000 
feet,  the  voltage  from  the  positive  logarithmic  output  decreases  from 
+5  volts  down  to  0  volts.  For  this  range  of  visibilities,  the 
negative  logarithmic  output  remains  at  0  volts.  As  the  visibility 
increases  above  20,000  feet,  the  positive  logarithmic  output  remains 
at  0  volts  while  the  negative  logarithmic  output  goes  from  0  volts  to 
an  upper  1  mit  of  +5  volts.  The  linear  output  from  the  sensor  is  not 
used  in  our  test  configuration.  To  preserve  the  signal  integrity, 
both  the  positive  and  negative  logarithmic  output  voltages  from  the 
sensor  are  converted  to  their  equivalent  digital  values  by  a  nearby 
analog  to  digital  (A/O)  converter  and  then  transmitted  from  the  Dulles 
center  field  location  back  to  the  main  processor  at  the  Weather 
Service  Office  (WSO).  Although  the  remote  A/D  converter  samples  the 
visibility  sensor  10  times  per  second,  the  processing  algorithm  only 
inputs  a  new  sample  every  10  seconds  and  then  computes  a  10  minute 
running  average  for  the  processed  output. 

2  Development  and  Calibration  of  the  Forward  Scatter  Visibility 
Meter,  Mar. ,1974,  Report  No .AFCRL-TR-74-0145. 
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2.1.3  Temperature  and  Dew  Point 

The  basic  transducers  used  for  both  temperature  and  dew  point  are  made 
by  the  Yellow  Springs  Instrument  Co.  (YSI)  and  have  been  used  in  over 
100  AM0S(Automatic  Meteorological  Observing  System)  and  RAMOS(Remote 
Automatic  Meteorological  Observing  System)  systems  built  and  operated 
by  the  National  Weather  Service  for  several  years.  They  are  enclosed 
in  a  Gill  Aspirated  Temperature>Oew  Point  Radiation  Shield.  A 
photograph  of  the  enclosure  is  shown  in  figure  2-5.  Both  sensors  are 
operated  in  a  voltage  mode  configuration  and  their  voltage  outputs  are 
converted  to  their  equivalent  digital  values  in  the  remote 
analog-to-digital  converter,  co-located  with  the  sensors,  before  being 
sent  to  the  processor  in  the  WSO  building. 

Temperature  data  is  obtained  by  placing  the  YSI  thermistor,  a  triple 
element  thermistor  component  whose  resistance  is  a  function  of 
temperature,  into  a  circuit  where  the  voltage  across  the  thermistor 
circuit  varies  linearly  with  temperature.  In  our  application,  the 
voltage  output  varies  10  millivolts  per  degree  Fahrenheit. 

The  dew  point  probe  consists  of  the  same  type  thermistor  component 
discussed  above,  a  bobbin  assembly  and  a  protective  shield. 
Construction  of  the  bobbin  assembly  is  made  by  using  lithium  chloride 
(LiCI)  impregnated  wicking  wound  around  a  spool  and  gold  bifilar 
electrodes  wound  on  top  of  the  wicking.  When  the  vapor  pressure  of 
the  surrounding  air  becomes  greater  than  that  of  the  LiCI  solution  in 
the  wicking  then  water  is  absorbed  into  the  solution.  The  wicking 
becomes  conductive  and  heat  is  generated  when  current  is  passed 
through  the  electrodes.  Eventually  a  heat-moisture  equilibrium  is 
reached  where  the  air  vapor  pressure  equals  that  of  the  LiCI  solution 
and  that  temperature  is  sensed  by  the  thermistor  component  as  the  dew 
point  temperature. 

Specifications  for  both  sensors  are  shown  below. 

RANGE. . . 

Temperature:  -58  to  +122  degrees  Fahrenheit 
Dew  Point:  -10  to  +86  "  '' 

ACCURACY. . . 

Temperature:  +/-  1.0  degrees  Fahrenheit  RMSE 

Dew  Point:  +/-  1.5  *'  "  "  (between  +30  and  +86 

degrees  F . ) 

+/-  2.5  "  "  "  (between  -10  and  +30 

degrees  F . ) 

2.1.4  Wind  Speed  and  Direction 

The  RAMOS  (Remote  Automatic  Meteorological  Observing  System)  wind 
speed  and  direction  sensors  have  been  selected  for  the  ALWOS  test 
because  of  their  high  accuracy,  fast  response,  and  low  failure  rate. 
The  wind  speed  and  direction  sensors  have  been  evaluated  in  several 
field  installations  and  have  proven  their  accuracy  and  reliability.  A 
photograph  of  both  units  is  shown  in  figure  2-6. 

The  wind  speed  sensor  is  basically  a  three  cup  anemometer  driving  a 
direct  current  generator,  which  is  designed  to  provide  a  linear 
relationship  between  wind  speed  and  generator  output  voltage.  The 


RAMOS  Wind  Dirnction  And  Wind  Spnnd  SnnAors 


Figurn  2-6 
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output  voltage  of  the  generator  is  put  across  a  potentiometer  which  is 
adjusted  such  that  1  knot  equals  10  millivolts.  With  proper 
averaging,  the  output  of  the  RAMOS  wind  speed  data  is  designed  to  be 
within  2  knots  or  5%  from  0  to  125  knots  of  a  1-minute  mean  of  the 
trut  value  of  the  wind  speed.  The  generator  has  an 
MTBF(mean-t ime-between-fai lures)  of  one  hundred  million  revolutions, 
which  in  our  application  translates  to  about  2  years  at  an  average 
wind  speed  of  8  knots.  Wind  tunnel  tests  have  shown  that  the 
anemometer  cup  assembly  can  withstand  wind  speeds  up  to  175  knots. 

Wind  direction  data  is  provided  by  a  sensor  that  is  basically  a  vane 
driving  a  multi-tap  potentiometer,  which  is  designed  to  provide  a 
linear  relationship  between  wind  direction  and  the  potentiometer's 
output  tap  voltages.  The  potentiometer  is  made  of  conductive  plastic 
and  is  estimated  to  have  a  useful  life  of  10  years  in  the  natural 
environment.  The  vane  features  a  long  moment  arm  and  a  polyurethane 
tail  which  provides  a  more  sensitive  and  faster  response  than  the 
current  National  Weather  Service  standard,  the  F420  steel  vane.  Wind 
direction  output  data  is  designed  to  be  accurate  to  within  10  degrees 
from  0  to  360  degrees  of  a  1-minute  mean  of  the  true  value  of  the  wind 
direction . 

2.1.5  Pressure/Al t imeter  Setting 

In  February, 1977,  NWS  issued  a  technical  specification  for  an 
accurate,  rugged  and  low-cost  pressure  sensor  that  could  be  easily 
adapted  to  automated  weather  stations.  The  Airesearch  Division  of 
Garrett  ''orporation  was  selected  from  among  several  competing  firms. 
All  of  their  delivered  units  have  been  tested  by  NWS  for  temperature, 
linearity,  hysteresis  and  power  fluctuation  effects  on  the  sensor's 
data.  In  addition,  the  sensors  are  undergoing  repeatability  and 
long-term  stability  tests  and  to  date  their  performance  has  been 
excellent.  In  the  ALWOS  system,  two  sensors  are  used  to  provide 
stat  on  pressure/a 1 t imeter  setting  data  and  are  co-located  with  the 
microprocessor  system.  Altimeter  setting  is  derived  from  the  station 
press'ire  by  using  the  appropriate  elevation  constants  for  Dulles 
Airport.  The  decision  to  use  two  sensors  for  altimeter  setting  was 
based  on  the  rel  tive  importance  of  the  parameter  to  aviation  safety 
and  the  relative  low-cost  of  the  sensor.  Operationally,  both  sensors 
have  to  track  on*  another  within  0.04  inches  of  mercury  for  altimeter 
setting  data  to  be  reported. 

The  pressure  sensor  assembly  consists  of  a  pressure  transducer  inside 
a  temperature  controlled  oven  and  a  power  supply.  A  fused  quartz 
diaphragm  is  attached  to  a  moving  electrode  that  forms  one  plate  of  a 
variable  capacitor.  The  opposite  electrode  or  capacitor  plate  is 
fixed  ^nd  as  the  applied  atmospheric  pressure  changes,  the  deflection 
of  the  diaphragm  causes  a  corresponding  change  in  the  measured  value 
of  capacitance.  This  capacitance  is  integrated  into  a  circuit  which 
provides  a  voltage  output  that  is  linear  with  applied  pressure. 

Conve  sin  of  the  sensor's  analog  output  voltage  to  the  equivalent 
digital  value  is  performed  in  a  local  analog-to-digital  converter  card 
located  in  the  processing  chassis.  The  range  and  accuracy  of  the 
sensor  is  listed  below. 

Range:  60  kilopascals  (kPa)  (17.718  in.  Hg.'i  to  106  kPa  (31.302  in. 

Hg.).  The  sensor's  output  voltage  is  linear  from  O.OOOv  to 

4.600V  at  O.OOlv/O.OIkPa. 
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Accuracy:  +/-  0.15  %  of  full  range  -  46  kPa  (13.584  In.Hg.) 

Worst  case  error  *  +/-  0.02  in.Hg. 

2.1.6  Precipitation  Yes/No 

A  precipitation  yes/no  sensor  manufactured  by  Wong  Laboratories  and 
distributed  through  Science  Associates,  Inc.,  model  #598(2),  was 
selected  for  use  in  the  ALWOS  system.  The  sensor  is  designed  to 
detect  the  presence  of  rain  and  snow  through  the  use  of  two  printed 
circuit-type  grids,  measuring  approximately  2x3  inches,  and  mounted 
on  a  sloping  surface  sensor  head  that  is  thermostatically  heated 
(figure  2-7).  Precipitation  is  indicated  whenever  rain  or  snow  bridge 
the  conductors  and  cause  a  change  in  the  detection  circuitry's 
resistance.  The  heating  element  is  used  to  assist  in  the  evaporation 
of  detected  precipitation  and  to  prevent  false  indications  due  to 
moisture  condensation  on  the  sensor  grids. 

A  50-foot  cable  connects  the  sensor  head  to  a  control  box  which 
includes  a  gain  control  knob  for  varying  sensitivity,  an  indicator 
light,  a  test  button  for  checking  performance  through  a  reference 
resistance  and  input-output  connection  terminals.  A  relay  contact 
closure  is  used  to  indicate  precipitation  occurrence  to  the  ALWOS 
processor. 

2.1.7  Thunderstorm 

The  thunderstorm  sensor  selected  for  ALWOS  ,  model  FCM-1,  is  a 
prototype  unit  manufactured  by  Atlantic  Scientific  Corporation. 
According  to  the  manufacturer,  the  FCM-1  Lightning  Warning  System  has 
an  adjustable  range  up  to  80  miles.  A  complete  system  is  comprised  of 
a  central  processor,  a  receiver  module,  antenna  assembly  and  data 
interconnect  cable.  The  sensor's  central  processor  provides  a  display 
of  the  number  of  lightning  discharges  detected  over  a  selectable 
period  of  time  and  an  alarm  which  is  energized  whenever  a  lightning 
stroke  is  monitored.  In  the  ALWOS  application,  however,  the  FCM-1 
central  processor  is  not  used  since  the  sensor's  receiver  module 
output  is  connected  directly  to  the  ALWOS  processor.  A  9  foot’whip 
antenna  and  the  receiver  module  are  mounted  at  the  top  of  a  20  foot 
Rohn  tower  located  at  Dulles'  centerfield.  The  yes/no  logic  level 
output  from  the  receiver  module  is  buffered  by  a  line  driver  before 
the  data  is  sent  to  the  ALWOS  processor  in  the  WSO  building. 

2.1.8  Day/Night 

Oay/night  information  is  required  by  the  visibility  module  in 
selecting  the  correct  processing  algorithm.  The  sensor  chosen  is 
manufactured  by  Precision  Multiple  Controls,  Inc.  and  is  simply  a 
photoelectric  cell  that  senses  the  amount  of  light  and  switches  115 
VAC.  off  and  on  at  its  output  as  a  function  of  day  or  night 
respectively.  In  the  ALWOS  application,  the  switched  AC  output  of  the 
sensor  is  used  to  drive  a  relay  that  provides  open  or  closed  contacts 
to  the  ALWOS  sensing  circuit.  For  the  ALWOS  test  at  Dulles,  the 
day/night  switch  was  mounted  on  the  roof  of  the  WSO  building. 
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2.2  Data  Processing  Equipment 

Figure  2-8  shows  a  card-level  block  diagram  of  the  ALWOS  system 
including  the  nine  printed-circuit  cards  that  plug  into  the  ALWOS 
system  chassis  and  perform  the  data  input,  output  and  processing 
functions  as  well  as  the  sensors  and  remote  analog  to  digital 
conversion  equipment  located  at  Dulles'  center  field  site.  Each  of 
the  nine  cards,  with  the  exception  of  the  sensor  input  card,  access 
the  systems'  address,  data  and  control  bus.  This  bus  architecture 
provides  a  convenient  means  for  a  CPU  card  to  pass  data  and/or  control 
to  and  from  any  other  card  connected  to  the  bus  as  well  as  accessing 
memory  locations  on  other  cards  to  allow  additional  programming  area. 
One  of  the  ALWOS  design  goals  was  to  eliminate  any  electromechanical 
storage  devices  such  as  magnetic  disk  units  that  are  inherently  less 
reliable  than  solid  state  memory.  As  a  result,  the  entire  ALWOS 
software  program  is  contained  in  read-only-memory  (ROM)  integrated 
circuits  mounted  on  the  2  CPU  cards  and  the  RAM/ROM  &  I/O  Expansion 
card.  A  multi-master  configuration  is  also  possible  where  more  than 
one  CPU  card  can  access  the  system  resources  over  the  same  bus  in  a 
time-multiplexed  arrangement.  In  the  ALWOS  system  we  have  2  CPU 
cards.  The  main  or  master  CPU  card  controls  the  overall  operation  of 
the  ALWOS  system  and  the  second  CPU  card  is  dedicated  to  ceilometer 
data  processing.  The  function  of  each  of  the  9  cards  and  the  remote 
analog  to  digital  converter  system  are  discussed  in  more  detail  in  the 
following  sections. 

2.2.1  Computer  Configuration 

An  MB80  Microcomputer  Chassis  built  by  Computer  Marketing,  Inc.  was 
selected  for  the  ALWOS  system  chassis.  The  MB80  provides  a  9  slot 
card  cage,  backplane,  power  supplies,  full  ASCII  keyboard, 
cathode-ray-tube  (CRT)  display  and  front  panel  control  assembly.  Its 
backplane  is  intended  to  interface  with  printed  circuit  cards  that 
conform  to  the  Intel  "MULTIBUS'*  configuration.  Included  with  the 
purchase  of  the  MB80  system  are  an  Intel  iSBC  80/20-4  central 
processing  unit  (CPU)  card  and  a  Data  Cube  video  random  access  memory 
(RAM)  card  to  drive  the  CRT  display.  A  dimensional  outline  of  the 
MB80  chassis  is  shown  in  figure  2-9. 

2.2. 1 . 1  Main  CPU  Card 

An  iSBC  80/20-4  single  board  computer,  manufactured  by  Intel  Corp.  and 
second-sourced  by  National  Semiconductor  Corp.,  is  used  for  the  ALWOS 
main  central  processing  unit  (CPU).  Each  iSBC  80/20-4  card  is  a 
complete  computer  system  in  itself  and  includes  the  CPU,  system  clock, 
4k  bytes  of  read/write  random  access  memory  (RAM),  sockets  for  8k 
bytes  of  non-volatile  read  only  memory  (ROM),  priority  interrupt  logic 
and  a  variety  of  input-output  interfaces. 

In  our  configuration,  the  main  CPU  card  is  the  master  or  executive  of 
the  ALWOS  system  operation.  It's  responsible  for  all  data  inputs, 
data  processing  and  system  outputs  with  the  exception  of  ceilometer 
data.  (A  separate  CPU  card  handles  the  ceilometer  data  processing  and 
will  be  discussed  in  a  following  section.) 
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The  ALWOS  hardware/software  configuration  is  designed  as  a  real-time 
interrupt  driven  system  that  incorporates  a  time  scheduling 
executive.  An  Intel  8259  Programmable  Interrupt  Controller  (PIC) 
provides  hardware  vectoring  for  eight  interrupt  levels.  The  fully 
nested  interrupt  mode  was  selected  of  the  four  modes  available  and 
operates  such  that  interrupt  level  0  remains  fixed  as  the  highest 
priority  and  level  7  as  the  lowest.  Six  separate  external  hardware 
interrupt  lines  are  processed  by  the  PIC  on  the  main  CPU  card  and  they 
are: 

level  2  -  Keyboard 

level  3  -  Cloud  Message  Input  Characters 

level  4  -  Remote  A/0  #1 

level  5  -  Remote  A/D  #2 

level  6  -  Real-Time-Clock 

level  7  -  Low-Level  Voltage  Detect 

Keyboard  data  enters  the  system  through  a  connector  at  the  back  of  the 
Video  Ram  card  (03)  .  Each  keystroke  generates  a  level  2  interrupt 
request  on  the  Video  Ram  card  and  is  passed  on  to  the  main  CPU  card 
for  servicing  via  the  systems'  MULTIBUS  backpanel  wiring.  The 
processing  of  the  keyboard  interrupt  and  data  is  described  in  sections 
3.2.2  Interrupt  Handlers  and  3.5  Keyboard  Processor. 

Remote  A/D  #1  data  is  presented  to  the  main  CPU  card  every  6 
milliseconds,  or  160  words  per  second,  which  is  the  conversion  rate  of 
the  remote  A/D  system.  Since  there  are  16  separate  channels  of  data 
being  converted,  each  channel  or  parameter  is  updated  10  times  each 
second.  The  data  is  transferred  16  bits  at  a  time  through  parallel 
I/O  ports  at  connector  J2  on  the  rear  of  the  card.  A  "data  ready" 
signal  accompanies  each  new  16  bit  word  presented  to  the  card  and 
causes  a  level  4  interrupt  to  be  sent  to  the  CPU  module  signifying 
that  new  data  is  available  for  input.  The  format  of  the  transferred 
data  for  both  remote  A/D  #1  and  #2  is  described  under  sections  3.2.2 
Interrupt  Handlers  and  3.4  Sensor  Data  Conversion  and  Processing. 

The  processed  cloud  message  is  transferred  from  the  ceilometer  CPU 
card  to  the  main  CPU  card  to  be  included  as  an  integral  part  of  the 
processed  ALWOS  output  message.  Processed  cloud  data  of  up  to  50 
characters  (not  to  be  confused  with  the  ceilometer's  raw  data  message) 
are  sent  in  a  serial  RS-232  format  at  110  baud  to  the  main  CPU  via 
rear  connector  03.  Each  character  received  generates  a  level  3 
interrupt  request  on  the  main  CPU  card.  A  new  cloud  message  is 
transmitted  by  the  ceilometer  CPU  card  approximately  every  4  minutes. 

Remote  A/D  #2  data  is  presented  to  the  system  at  the  same  rate  as 
remote  A/D  #1.  However,  remote  A/D  #2  data  enters  the  system  through  , 

connector  02  at  the  rear  of  the  RAM/ROM  and  I/O  Expansion  card.  For 
each  16  bit  parallel  word  transferred,  a  level  5  interrupt  request  is 
generated  on  the  RAM/ROM  card  and  is  passed  on  to  the  main  CPU  card 
via  the  "MULTIBUS"  backplane  for  servicing.  A  more  detailed  * 

discussion  of  the  remote  A/D  system  operation  is  contained  in  section 
2.3  Remote  Analog  to  Digital  Converter  System. 

The  real-time-clock  card  issues  an  interrupt  request  to  the  main  CPU 
card  once  a  second.  Its  level  6  request  is  also  sent  to  the  main  CPU 
through  the  MULTIBUS  backplane  and  is  used  as  the  basic  time  keeping 
mechanism  for  the  time  scheduling  executive  software.  Servicing  the 
clock  interrupt  is  described  in  section  3.2.2  Interrupt  Handlers. 

i 
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A  low  voltage  detection  circuit,  designed  by  NWS,  is  used  to  generate 
the  level  7  interrupt  request  to  the  main  CPU  card  and  halt  system 
operation.  The  purpose  of  the  signal  is  to  prevent  erratic  system 
behaviour  whenever  the  voltage  level  supplied  to  the  processing 
circuitry  drops  to  a  marginally  low  level  for  reliable  computer 
operation.  The  low  voltage  condition  could  be  caused  by  power  supply 
failure,  long  or  short  term  power  line  voltage  drop  or  by  the  onset  of 
a  complete  power  failure.  The  main  CPU  card  is  programmed  to  respond 
to  the  level  7  interrupt  by  executing  a  “halt"  instruction. 

Event  type  sensor  data  and  control  signals  are  transferred  in  parallel 
format  to  and  from  connector  J1  at  the  rear  of  the  card.  Day/Night, 
Precipitation  Yes/No  and  Thunderstorm  Yes/No  data  are  presented  in  a 
binary  format  as  a  logical  one  or  zero  to  the  parallel  interface  and 
are  sampled  once  each  second.  Two  lines  of  the  parallel  I/O  connector 
J1  are  used  to  pass  visibility  information  to  the  ceilometer  CPU 
card.  One  bit  is  used  to  indicate  whether  visibility  data  is  missing 
or  not  and  the  other  bit  is  used  to  indicate  whether  the  reported 
visibility  is  greater  than  1.5  miles  or  not.  The  ceilometer  CPU  card 
uses  this  information  in  its  decision  to  report  cloud  data  missing  or 
not  and  whether  to  report  partial  or  total  obscuration  when  the 
visibility  is  less  than  or  equal  to  1.5  miles. 

A  serial  input/output  port  at  the  third  rear  connector,  J3,  is  used  to 
receive  the  ceilometer  CPU's  processed  cloud  message,  transmitted 
approximately  every  4  minutes.  The  format  of  the  transmitted  data  is 
described  in  section  2.1.1,  Ceilometer. 

Random-AccesS'Memory  (RAM),  used  for  temporary  data  storage,  is  jumper 
selected  on  the  main  CPU  card  to  occupy  4k  bytes  of  total  system 
memory  space  from  7000  through  7FFF  HEX.  Read-Only-Memory  (ROM),  used 
for  permanent  program  storage,  is  Jumper  selected  on  the  main  CPU  card 
to  occupy  8k  bytes  of  system  memory  from  0  through  IFFF  HEX.  A 
complete  map  of  the  ALWOS  system  memory  configuration  is  found  in 
section  3.,  Software  Configuration. 

Additional  technical  details  on  this  card  are  provided  in  the  Intel 
80/20-4  Hardware  Reference  Manual. 
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2. 2. 1.2  Ceilometer  CPU  Card 

An  Intel  iSBC  80/20-4  single  board  computer  card  is  also  used  for 
the  ceilometer  input/output  and  data  processing  functions.  The 
additional  CPU  card  provides  a  means  to  input  ceilometer  data 
through  a  serial  port  every  28  seconds,  store  and  process 
approximately  25  minutes  of  previous  cloud  data,  and  output  the 
formatted  message  independent  of  the  main  CPU  card's  operations. 

Like  the  main  CPU  card,  the  ceilometer  CPU  card  is  a  complete 
computer  system  in  itself  and  contains  the  CPU,  4k  bytes  of  RAM 
memory,  8k  bytes  of  ROM  memory,  priority  interrupt  logic  and  a 
variety  of  input-output  interfaces.  Each  CPU  card  operates 
independently  of  the  other  when  on-board  resources  (memory,  etc.) 
are  addressed  and  can  even  share  the  remainder  of  the  ALWOS  system 
resources  (additional  memory  and  I/O  ports,  etc.)  in  a  time-shared 
mode  of  the  system's  MULTIBUS  structure. 

Serial  data  is  received  from  the  Impulsphysik  ceilometer  at  110 
baud,  RS-232  format,  consists  of  65  characters  and  occurs  every  28 
seconds.  A  complete  description  of  the  ceilometer's  input  data 
format  is  found  in  Appendix  A  -  Cloud  Algorithm.  The  ceilometer  CPU 
card's  memory  is  configured  in  a  non-standard  arrangement  that 
places  its  80/20-4  RAM  memory  starting  address  at  1000  HEX  insteao 
of  3000  HEX.  A  memory  map  of  the  ceilometer  CPU  is  shown  below. 

0000  to  09FF  HEX  AUTOB  Algorithm  #2 

OAOO  to  OEDO  HEX  Cloud  Base  Height  Algorithm 

0EF8  to  OFFF  HEX  Floating  Point  Subroutine 

1000  to  17FF  HEX  RAM 

1800  to  IFFF  HEX  Floating  Point  Subroutine 

Approximately  every  4  minutes,  the  processed  cloud  message  is 
transmitted  serially  to  the  main  CPU  card  via  connector  03  at  the 
rear  of  the  card  and  is  included  with  the  other  parameters  to  form 
the  ALWOS  system  output  message.  However,  two  visibility  conditions 
are  required  by  the  ceilometer  algorithm  before  it  can  process  the 
cloud  data.  These  two  conditions  define  whether  a  visibility  value 
is  available  or  not  and  if  the  reported  visibility  is  greater  than 
or  less  than  1.5  miles.  This  information,  used  by  the  cloud 
algorithm  in  determining  obscuration  conditions,  is  received  by  the 
ceilometer  CPU  card  through  two  parallel  I/O  lines  of  connector  Jl. 
For  additional  information  on  the  ceilometer  CPU  card's 
configuration  or  operation,  see  Appendix  A,  ALWOS  Cloud  Algorithms. 

2. 2. 1.3  Clock  Card 

The  clock/calendar  timekeeping  functions  of  ALWOS  are  provided  by 
the  MC1460  Microcomputer  Timekeeping  Module  manufactured  by  Canada 
Systems  Inc.  This  card  is  fully  compatible  with  the  "MULTIBUS" 
configuration  and  interfaces  directly  to  the  ALWOS  system  bus. 

Month,  day,  hours,  minutes  and  seconds  information  are  transferred 
through  the  "MULTIBUS"  interface  to  the  main  CPU  card  for  use  by  the 
time  scheduling  executive  program.  Automatic  date  correction  is 
included  for  the  number  of  days  in  each  montn.  The  MC1460  operates 
with  an  external  battery,  added  to  the  MB80  chassis  by  NWS,  to 
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ensure  correct  date  and  time  data  when  system  power  is  restored 
following  a  power  failure.  In  addition,  the  card  offers  several 
software  and  switch  selectable  configurations,  some  of  which  are 
listed  below. 

Periodic  interrupts  to  the  main  CPU  card  are  available  at  any  of 
7  software  selectable  rates.  A  once  per  second  interrupt  rate 
was  selected  for  ALWOS.  Also,  there  are  8  possible  levels, 
level  0  through  level  7,  that  the  1  Hz  interrupt  can  be 
presented  to  the  main  CPU's  interrupt  controller.  Level  6  was 
switch  selected  for  the  real-time-clock  interrupt. 

Base  address  selection  of  8  sequential  I/O  ports  to  pass  clock 
data  and  control  words  to  and  from  the  main  CPU  card  is  also 
switch  selectable.  The  starting  I/O  base  address  selected  for 
ALWOS  is  CO  in  hexadecimal  (HEX)  code. 

A  50/60  Hz  line  frequency  switch  was  initially  set  for  60  Hz 
operation  and  provided  excellent  long  term  accuracy  when  the 
ALWOS  system  was  being  developed.  However,  when  the  system  was 
installed  at  Dulles  Airport,  excessive  noise  on  the  A/C  power 
lines  forced  us  to  modify  the  clock  board  and  install  an 
external  crystal  oscillator  as  the  basic  timekeeping  source. 

For  more  detailed  information  on  the  clock  card,  refer  to  the  MC1460 
Installation  and  Operotion  Manual. 

2.2. 1.4  Internal  Analog  to  Digital  (A/D)  Card 

The  Intel  iSBC  711  Analog  Input  Board  performs  the  basic  functions 
of  data  acquisition  of  analog  input  signals  under  control  of  the 
ALWOS  main  CPU  card.  It  consists  of  8  differential/16  single  ended 
channel  multiplexer,  input  protection  circuits,  programmable  gain 
amplifier,  sample  and  hold  amplifier,  12-bit  A/D  converter,  memory 
mapped  interface  and  control  logic.  The  card  is  MULTIBUS  compatible 
and  its  purpose  in  thf  ALWOS  system  is  to  digitize  the  analog 
voltage  outputs  of  the  two  local  pressure  sensors  to  determine 
station  pressure  and  altimeter  setting. 

In  the  ALWOS  system,  the  card  is  programmed  to  operate  in  a  random 
channel  input  mode,  with  a  gain  of  1  and  jumper  selected  for  a  0  to 
+5  volt  input.  The  iSBC  711  utilizes  a  memory  mapping  technique 
which  allows  all  control  and  data  transfer  operations  to  be 
referenced  as  memory  instructions  to  a  jumper  selected  base  address 
plus  offset.  A  base  address  of  5FF0  HEX  was  selected  for  ALWOS. 

Data  acquisition  begins  when  the  master  CPU  issues  a  write  command 
word  that  specifies  the  gain  and  channel  selection  to  the  iSBC  711 
card.  The  main  CPU  then  checks  for  the  completion  of  the  analog  to 
digital  conversion  cycle  by  continuously  reading  a  status  register 
on  the  A/D  card.  When  the  end  of  conversion  is  indicated,  the  main 
CPU  reads  in  the  12-bit  data.  A  software  timeout  is  included  in 
this  opeation  to  prevent  the  system  software  from  hanging  due  to 
possible  malfunction  of  the  card.  Analog  voltage  inputs  from 
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pressure  sensors  #1  and  #2  interface  the  A/0  card  as  channels  03  and 
04,  respectively.  In  addition,  two  corresponding  offset  voltages 
are  input  through  A/D  channels  15  and  14,  respectively,  and  are 
added  to  the  pressure  data.  These  adjustable  offset  voltages 
originate  from  the  Sensor  Input  Card  and  are  used  to  calibrate  the 
pressure  sensor  readings.  For  more  detailed  information  on  the 
card's  operation,  refer  to  the  Intel  iSBC  711  Hardware  Reference 
Manual  . 

2 . 2 . 1 . 5  Voice  Card 

Speech  Technology  Corporation  (STC)  manufactures  the  model  M180 
Voice  Generator  card  and  is  used  in  the  ALWOS  system  to  convert  the 
processed  weather  observation  into  its  equivalent  spoken  message.  A 
computer  analysis  of  the  spoken  ALWOS  vocabulary  was  performed  by 
STC  to  minimize  the  amount  of  storage  required  for  the  digitized 
vocabulary  while  striving  to  preserve  the  natural  voice  quality  and 
intonation.  The  resultant  digitized  ALWOS  vocabulary  is  stored  in 
four  programmable  read-only-memory  (PROM)  modules  that  are  inserted 
into  the  M180  card.  Approximately  70  words,  phrases  and  timed 
pauses  or  70  seconds  of  speech  are  contained  in  the  ALWOS  vocabulary 
and  are  listed  in  figure  2-10.  Each  word  or  phrase  is  output  by  the 
card  in  audio  form  whenever  the  appropriate  two-byte  PROM  address  is 
sent  to  the  Voice  card.  Input  data  rates  to  the  Voice  card  may  vary 
from  two  to  four  bytes  a  second  to  as  low  as  two  bytes  in  4  seconds, 
depending  on  whether  isolated  words  or  connected  phrases  are 
selected  from  the  vocabulary.  Internal  bit  rates  vary  from  600  to 
1100  bits  per  second  when  the  digitized  speech  is  converted  to  its 
analog  output.  Although  the  M180  Voice  Generator  card  is  compatible 
with  the  Intel  MULTIBUS,  word  or  phrase  address  data  is  transferred 
to  the  Voice  card  from  the  Output  card  via  J1  at  the  rear  of  the 
card.  For  additional  technical  information  on  this  card,  refer  to 
STC's  M188  Voice  Generator  User's  Reference  Manual. 

2 . 2 . 1 . 6  Output  Card 

The  Output  card,  designed  and  built  by  NWS,  provides  data  buffering 
and  interfaces  for  the  ALWOS  system  outputs.  Remote  display  (CRT) 
data,  remote  telephone  data  access,  local  printer,  local  cassette 
and  voice  data  are  all  handled  by  the  Output  card.  The  card 
receives  its  data  from  the  main  CPU  card  over  the  system's  MULTIBUS 
interface.  Three  on  board  buffers,  each  addressed  as  individual  I/O 
ports,  allow  the  main  CPU  to  store  processed  data  into  the  Ou*^^put 
card  at  set  times  and  for  the  data  to  be  transmitted  to  the  output 
peripherals  at  their  convenience.  This  configuration  lessens  the 
potential  peak  workload  or  duty  cycle  that  the  main  CPU  may 
encounter  at  system  update  times  by  allowing  the  Output  card  to 
handle  most  of  the  system  I/O. 


ALUOS  Automated  Voice  Vocabulary 
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Less  than. 
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S  i  X 

Clcuds 

Minus 
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Missing 

Sky 

Dew  point 

More  than 

Temperature 

Eight 
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Eighth 
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Estimated 

Obscured 

Thunderstorms 
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To/Two 
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Overcast 

Feet 

Visibility 
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Five 

PS200  (200  ms.  "  ) 

Wind 

Four 
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F  0  u  t  h 

PS800  (800  ms.  "  ) 
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Freezing  rain 

Partial  1y 
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Precipitation 

Phrases 

1.  Dulles  International  Airport  automated  weather  observed  at: 

2.  This  is  a  test 

3.  Sky  condition  missing 

4 .  Indef i n i te  ceiling 

5.  Index  of  visibility 

6.  Higher  clouds  detected 

7.  Clear  below 

8.  Variable  between 

9.  Favored  runway  changed  from 


Figure  2-10 
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The  first  output  buffer,  addressed  as  I/O  ports  84  and  85  HEX, 
stores  the  system's  one-minute  observation  at  00,  20  and  40  minutes 
after  the  hour  and  interfaces  its  data  to  the  local  cassette  tape 
recorder,  local  system  output  printer  and  remote  telephone  data 
access.  All  three  peripherals  are  connected  in  parallel  to  the 
buffer's  RS-232  serial  output.  Data  transmission  begins  when  the 
system  is  polled  via  the  telephone  data  access,  nominally  at  10,  30 
and  50  minutes  after  the  hour.  If  the  poll  is  not  received  during 
the  20  minute  interval  then  the  computer  forces  the  buffer  to 
transmit  its  data  at  19,  39  and  59  minutes  after  the  hour. 

The  second  buffer,  addressed  as  I/O  ports  82  and  83  HEX,  is  used  to 
store  and  transmit  data  through  a  serial  RS-232  interface  to  the 
remote  CRT  display  located  in  the  Dulles  Airport  control  tower. 

This  buffer  updates  and  transmits  the  latest  ALWOS  observation  every 
minute  to  the  remote  CRT. 

The  third  buffer  addressed  as  I/O  ports  80  and  81  HEX,  stores  a 
series  of  addresses  corresponding  to  words  or  phrases  that  are 
contained  in  the  ALWOS  system's  voice  message.  These  addresses  are 
transferred  in  an  8-bit  parallel  format  to  the  Voice  card  through 
ccnector  J1  at  the  rear  of  the  card.  A  new  voice  message  is  stored 
in  the  Output  card  every  minute.  Transfer  of  the  vocabulary 
addresses  from  the  Output  card  to  the  Voice  card  is  initiated  by  the 
main  CPU  card.  A  schematic  of  the  ALWOS  Output  (Data  Storage 
Interface)  card  is  provided  under  separate  cover. 

2. 2. 1.7  Sensor  Input  Card 

The  sensor  input  card  was  designed  by  NWS  as  a  means  of  providing 
special  purpose  circuitry  that  allows  increased  interface 
flexibility  to  a  variety  of  sensors.  Included  in  the  special 
circuitry  are  two  adjustable  pressure  offset  voltages  that  are  used 
in  the  calibration  of  the  two  pressure  sensors.  The  pressure  offset 
voltages,  #1  and  #2,  are  interfaced  through  connectors  at  the  rear 
of  the  card  to  channels  15  and  14  of  the  internal  A/D  card, 
respectively.  In  addition,  a  3.333vdc  calibration  check  voltage  is 
generated  on  the  card  and  tied  to  channel  13  of  the  internal  A/D 
card.  Software  then  compares  the  digitized  value  to  be  within 
predetermined  limits  as  a  quality  control  check  of  the  internal  A/D 
converter  card.  Voltage  scalers,  input  filters  and  digital  latches 
are  also  provided  to  interface  the  thunderstorm,  precipitation  and 
day/night  sensors.  This  card  receives  power  from  the  MB80  MULTIBUS 
interface  but  does  not  transfer  any  data  or  control  signals  over  the 
bus.  All  input  and  output  data  transfers  are  done  through  the 
connectors  at  the  rear  of  the  card.  A  schematic  of  the  Sensor  Input 
Card  is  provided  as  a  separate  item. 

2. 2. 1.8  Video  Ram  Card 

A  DATACUBE  model  VR-107  video  RAM  (random-access-memory)  card  is 
used  to  drive  the  local  display  characters  on  the  ALWOS  chassis' 
integral  display.  The  card  contains  2k  bytes  of  RAM  memory  and  is 
fully  compatible  with  the  Intel  MULTIBUS  configuration  used  in  the 
ALWOS  system  chassis.  Dual  port  memory  provides  a  simple  means  of 
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writing  ASCII  characters  on  tne  screen.  Characters  are  written  into 
or  out  of  the  RAM  memory  from  the  MULTIBUS  side  while  the  other  port 
is  used  to  refresh  the  raster-scan  of  the  CRT  display.  A  character 
need  only  be  written  to  the  appropriate  location  in  the  video  RAM  in 
order  to  appear  instantly  on  the  screen.  The  character  generator 
provides  128  characters  including  upper  and  lower  case.  The  display 
is  normally  formatted  as  24  lines  of  80  characters  each  for  a  total 
of  1920  characters  but  can  be  programmed  to  display  larger 
characters  in  a  12  line  by  40  characters  per  line  format. 

Connectors  J2  and  J3  are  provided  at  the  rear  of  the  card  to 
interface  directly  to  the  CRT  display  and  an  8-bit  keyboard, 
respectively.  Characters  typed  on  the  MB80's  integral  keyboard 
enter  the  video  RAM  card  through  a  ribbon  cable  and  cause  an 
interrupt  to  be  sent  to  the  main  CPU  card.  When  a  keyboard 
interrupt  occurs,  the  main  CPU  reads  the  memory  location  that 
corresponds  to  the  keyboard  input  port  and  processes  the  keyboard 
command.  In  the  ALWOS  configuration,  the  2k  bytes  of  video  RAM 
memory  is  jumper  selected  to  occupy  locations  6800  HEX  to  6FFF  HEX. 
Also,  the  keyboard  interrupt  is  jumper  selected  to  generate  a  level 
2  interrupt  to  the  main  CPU  card.  For  additional  information  on  the 
Video  RAM  Card,  refer  to  the  DATACUBE  VR-107  Data  Sheet  and  VR-107 
Programmer's  Reference  Manual. 

2. 2. 1.9  RAM/ROM  and  Expansion  I/O  Card 

An  Intel  iSBC  116  Combination  Memory  and  I/O  Expansion  Board  is  used 
in  the  ALWOS  system  to  provide  both  additional  RAM/ROM  memory  and  to 
increase  the  system's  input-output  capability.  Each  iSBC  lib  offers 
16k  bytes  of  RAM  (read/write)  memory  and  sockets  for  up  to  8k  bytes 
of  ROM  (read  only)  memory.  It  interfaces  directly  with  the  main  CPU 
card  via  the  system  bus  and  provides  48  programmable  I/O  lines  as 
well  as  a  synchronous/asynchronous  RS-232  communications  interface. 

In  the  ALWOS  configuration,  the  iSBC  116  card  provides  the  system  an 
additional  parallel  input  for  the  back-up  channel  of  the  remote 
analog  to  digital  converter  system  (Remote  A/D  #2).  The  16-bit 
parallel  data  is  received  at  the  same  rate  and  format  as  that  of 
Remote  A/D  #1  but  generates  a  level  5  interrupt  request  to  the  main 
CPU  card  for  each  16-bit  word  transferred.  The  iSBC  RAM  and  ROM 
memory  provide  the  main  CPU  card  additional  temporary  storage 
locations  as  well  as  increased  fixed  program  area,  respectively.  RAM 
memory  on  the  iSBC  116  card  is  Jumper  selected  to  begin  at  address 
8000  HEX  and  continue  through  BFFF  HEX.  ROM  memory  is  jumper 
selected  to  begin  at  2000  HEX  and  continue  through  3FFF  HEX.  For 
more  detailed  technical  data  on  this  card,  refer  to  the  Intel  iSBC 
116  Hardware  Reference  Manual.  Also,  refer  to  section  2.3  for 
additional  information  on  the  Remote  Analog  to  Digital  Converter 
System. 

2.3  Remote  Analog  to  Digital  Converter  System 

The  remote  analog  to  digital  converter  system  is  used  to  digitize 
the  ALWOS  analog  sensor  outputs  located  at  Dulles  Airport 
centerfield  and  to  transmit  the  informtion  back  to  the  ALWOS 
computer  chassis  for  processing.  Due  to  the  estimated  half  mile  or 
longer  cable  run  between  the  centerfield  sensor  site  and  the  ALWOS 


processor  located  in  the  Dulles  WSO  building,  it  was  decided  to 
digitize  the  analog  signals  at  the  centerfield  site.  The  remote  A/D 
system  used  in  the  ALWOS  test  was  supplied  by  FAA's  Transportation 
System  Center  (TSC)  and  a  block  diagram  of  the  system  is  shown  in 
f i gure  2-11. 
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Analog  outputs  from  the  temperature,  dew  point,  wind  speed,  wind 
direction,  and  visibility  sensors,  as  well  as  reference  voltages, 
are  connected  to  the  co-located  remote  A/D  system  through  assigned 
channels  of  the  input  multiplexer  and  are  listed  in  Section  3.4 
Sensor  Data  Conversion  and  Processing.  Each  input  to  the  remote  A/D 
system  is  actually  connected  in  parallel  to  a  second  or  back-up  A/D 
converter  system.  In  the  block  diagram  and  elsewhere  in  this  text, 
the  main  A/D  system  and  its  identical  back-up  A/D  system  are 
referred  to  as  remote  A/D  #1  and  remote  A/D  #2,  respectively. 

Sensor  inputs  to  the  16  channel  input  multiplexer  are  scanned 
sequentially  at  a  160  Hz. rate  (10  updates  per  second  for  a  given 
parameter)  and  digited  by  the  A/0  converter  module.  The  digitized 
data  is  then  transmitted  in  a  bit  serial  format  by  modem  over  cable 
pair  back  to  the  WSO  building  where  the  data  is  received  by  a 
similar  modem,  assembled  into  a  parallel  format  and  presented  to  an 
I/O  port  on  either  the  main  CPU  or  RAM/ROM  &  Expansion  I/O  card. 

A/D  conversion  and  transmission  of  the  sensor  data  to  the  ALWOS 
processor  is  done  continuously  by  both  systems.  Parallel  data  is 
formatted  in  a  16  bit  word  where  the  most  significant  4  bits 
represent  the  channel  number  (0-15)  and  the  least  significant  12 
bits  contain  the  digitized  voltage  (1.221  millivolts/bit).  For 
additional  information  on  the  remote  A/D  converter  system,  refer  to 
Sections  3.2.2  Interrupt  Handlers  and  3.3  Sensor  Data  Collection. 


Processed  data  Is  output  from  the  ALWOS  system  to  a  local  printer, 
local  CRT  display,  remote  CRT  display,  remote  voice  output  and 
remote  telephone  dial-up.  A  local  cassette  recorder  was  also  part 
of  the  original  system  output  but  was  removed  when  Its  operation 
became  erratic. 

The  local  printer,  Texas  Instruments'  model  745,  operates  at  300 
baud  and  prints  a  one  minute  observation  message  every  20  minutes. 
An  example  of  Its  printout  and  explanation  of  each  parameter  Is 
shown  below. 
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The  local  printer  and  the  remote  telephone  dial-up  receive  data  from 
the  same  storage  buffer  of  the  ALWOS  Output  card.  The  one  minute 
observation,  stored  at  00,  20  and  40  minutes  after  the  hour.  Is 
transmitted  to  both  the  local  printer  and  the  remote  telephone 
dial-up  whenever  the  telephone  Interfaced  Is  polled,  nominally  at 
10,  30  and  50  minutes  after  the  hour.  If  the  telephone  Is  not 
polled  in  the  20  minutes  Interval,  the  software  forces  the  data  to 
be  transmitted  to  tne  local  printer  at  19,  39  and  59  minutes  after 
the  hour.  A  status  word,  described  In  Section  3.9  Accounting,  would 
have  appeared  at  the  end  of  the  message  If  the  system  had  detected 
any  recent  errors  within  the  system. 


The  voice  output  speaker  Is  located  on  the  11th  floor  of  the  Dulles 
Airport  tower  adjacent  to  the  remote  CRT  display  where  both  ALWOS 
outputs  are  available  to  FAA  personnel  for  evaluation. 

Voice  messages  are  updated  and  output  every  minute  and  are 
essentially  a  spoken  version  of  the  ALWOS  one-minute  observation. 
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Previous  automated  tests  have  demonstrated  that  these  voice  messages 
can  successfully  be  transmitted  to  nearby  pilots  via  radio  link  for 
an  up-to-date  weather  observation  while  enroute.  A  cassette 
recording  of  the  ALUOS  voice  output  is  included  as  a  separate 
del iverable. 

The  remote  CRT  receives  its  data  in  an  ASCII  serial  format  at  300 
baud  and  displays  a  new  ALWOS  observation  every  minute.  When  a  new 
observation  is  received  and  displayed  at  the  bottom  of  the  CRT,  the 
previous  one-minute  observations  are  scrolled  up  such  that  the 
previous  11  observations  are  displayed. 

The  local  CRT  or  maintenance  display  is  an  integral  part  of  the 
ALWOS  MB80  chassis  and  is  programmed  to  offer  four  different  display 
modes  under  keyboard  control:  norma  1 .  observation,  accounting  and 
maintenance .  The  normal  display  mode  includes  only  the  month,  day 
and  Greenwich  Mean  Time  (GMT)  information  at  the  top  of  the  screen 
with  a  CPU  idle  time  percentage  displayed  in  the  upper  right 
corner.  The  nearly-blank  screen  is  used  in  normal  operation  during 
the  test  period  at  Dulles  to  prevent  any  biasing  of  the  Dulles 
observers  by  the  ALWOS  observation.  This  mode  is  selected  whenever 
the  system  has  been  powered  up,  rebooted,  or  the  "RSTR"  (restart) 
key  is  depressed. 

The  local  CRT's  observation  mode  displays  several  of  the  sensors' 
one-minute  averages  in  the  upper  half  of  the  display  as  well  as  the 
system's  formatted  output  message  in  the  bottom  half(figure  2-12). 
This  mode  is  entered  from  the  norma  1  mode  by  depressing  the  "CTRL" 
(control),  and  "SHIFT"  keys  simultaneously. 

09:15:13:43:28  91 


TEMPERATURE  72  DEWPOINT  68 

WINOOIR  36  PRESSURE29513 

SPEED  4  29513 

PEAK  5  VISIBILITY  3 


3  P  B  0  1  E  2  0 
72/67/3604/986 
CLRBL030 

Local  Display  in  Observation  Mode 
Figure  2-12 

(Note-  The  '91'  in  the  upper  right  corner  of  the  display 
represents  the  main  CPU's  idle  time  percentage  for  the  previous 
second.  In  other  words,  the  processor  was  idling  91  percent  of  the 
time  during  the  27^  second  after  the  minute.  This  number  decreases 
appreciably  at  10  second  Intervals  and  on  the  minute  when  the 
processor  has  a  greater  workload.) 


The  aceeanting  mode,  entered  from  either  the  normal  or  observation 
mode  by  depressing  the  "ACCT“  key,  displays  on  the  bottom  half  of 
the  local  CRT  errors  that  the  system  has  detected  for  each  parameter 
during  the  last  hour  and  24  hour  periods.  This  mode  also  displays 
the  date  and  time  (Greenwich)  of  the  last  total  system  restart  due 
to  power  up,  resetting  the  system  clock  or  rebooting  the  system 
through  the  front  panel  switch.  The  top  half  of  the  display  will 
also  contain  the  observation  mode  data  if  the  accounting  mode  was 
entered  following  the  observation  mode.  This  sequence  is  shown  in 
figure  2-13.  The  displayed  accounting  data  is  updated  only  when  the 
"ACCT"  key  is  depressed. 
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Local  Display  in  Accounting  Mode 
Figure  2-13 


(Note:  System  has  detected  one  error  in  Remote  A/D  #1  (RADI)  and 
Remote  A/D  #2  (RAD2)  since  9/15  00  hours  GMT) 


r 


The  maintenance  mode  on  the  local  CRT  is  entered  from  the  normal  or 
observation  modes  by  depressing  either  the  “MNT/l  SEC",  "MNT/5  SEC 
or  "MNT/OMO"  keys.  Maintenance  data  are  then  displayed  on  the  lower 
half  of  the  CRT  and  updated  every  second,  every  5  seconds  or  upon 
keystroke  demand,  respectively.  Remote  digital  data,  representing 
the  16  channels  of  digitized  voltages  from  the  selected  remote  A/D 
converter  system,  are  displayed  as  well  as  digital  pressure  values 
and  offsets  converted  by  the  local  A/D  converter  card.  The  actual 
sensor  voltages  can  be  obtained  for  analysis  by  multiplying  the 
digitized  values  by  1.221  millivolts  per  bit.  The  format  of  the 
ALWOS  display  in  the  ma i ntenance  mode  (following  an  observat i on 
mode)  is  shown  in  figure  2-14. 
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Local  Display  in  Maintenance  Mode 
Figure  2-14 


The  remote  A/D  channel  assignments  are  found  in  section  3.4  Sensor 
Data  Conversion  and  Processing. 


2.5  Hardware  Cost  Analysis 


The  cost  of  the  ALWOS  system's  component  parts,  as  purchased  In 
1979,  are  shown  in  figure  2-15.  As  stated  earlier  in  this  document, 
the  cost  of  the  ceilometer  and  visibility  sensors  far  exceed  the 
cumulative  cost  of  the  remaining  sensors  and  processing  equipment. 
When  our  prototype  laser  ceilometer  was  originally  purchased  in 
1979,  its  price  was  $47,000.  A  1981  purchase  of  a  similar 
ceilometer,  also  from  Impulsphysik,  was  priced  at  $25,000  and 
hopefully  indicates  that  the  cost  of  this  type  of  ceilometer  will 
drop  as  the  technology  becomes  further  developed.  Also,  the  cost 
(and  the  size)  of  the  data  processing  equipment  necessary  for  an 
automatic  weather  observation  station  has  continued  to  decrease.  In 
1974,  when  the  AV-AUOS  minicomputer  system  was  purchased,  the  data 
processing  equipment  necessary  to  perform  that  task  cost 
approximately  $60,000  and  required  two  19"  wide  by  6  feet  tall  racks 
to  hold  the  equipment.  Conversely,  the  ALWOS  processing  equipment 
cost  approximately  $9,000  in  1979  and  fits  into  a  desk  top  chassis. 


ALWOS  SYSTEM  COMPONENTS’  COST  (AS  TESTED  AT  DULLES  AIRPORT 


o 

VO  o  O  lO  VO 

o  o  ^r^ 

o 

VO  00  VO  (*>  CM 

O  O  VO 

VO 

00  •-  00  o  >» 

no  a\ 

* 

»  * 

* 

no 

•“  — 

00 

o  o  o  o  o 
o  o  o  o  o 
^  ^  ro  ^ 


c\j  ^ 


—  <NJ 


• 

• 

• 

• 

1 

1 

•  • 

• 

•  •  • 

• 

• 

• 

• 

• 

• 

1 

1 

*  • 

• 

•  •  • 

1 

<D 

1 

0) 

• 

■ 

• 

• 

• 

1 

•  • 

•  • 

1 

o 

1 

C 

o 

4/> 

• 

• 

• 

1 

•  * 

•  •  CM 

*0 

o 

1 

o 

o 

CM  I— 

1 

o 

Q. 

1  0^ 

#0 

liT  • 

• 

• 

• 

vr> 

• 

1 

.  o  • 

00  • 

\o 

1 

0> 

ON  <Si 

00 

1 

o 

•o 

tiO 

£ 

^  • 

• 

• 

1 

1 

•  no  • 

•  •  E 

ID 

1 

4»— «. 

x> 

-o  a» 

QC 

1 

0) 

1 

iA 

c 

O  -M 

• 

• 

• 

u 

1 

4-» 

to 

S  r-  (/> 

O 

01 

1 

• 

f  >v 

01 

u 

1. 

1 

C 

4-» 

<D 

!/>  S  (/) 

*o 

• 

• 

• 

Q. 

1 

3 

•  <A  • 

u 

0)  c_> 

w 

1 

o> 

3 

U.  "v. 

> 

o. 

1 

as 

4-> 

1. 

• 

1 

1 

•  c  • 

m 

o  .  o 

o9 

f— 

1 

r— 

o 

1. 

4J  -O  X 

•Hi 

£ 

1 

^  •»“ 

0) 

<o  O  1— 

Z3 

• 

01 

1 

a\ 

o. 

s-  s  * 

Q. 

E  3 

4-» 

1 

♦  • 

urs. 

£ 

o 

CJ 

«>  o. 

• 

oo 

0  3  0 

OJ 

z  > 

■w  o 

QO 

■O  CM 

4-» 

lO  C 

•f" 

c 

< 

&. 

O 

Z  O 

_i  o  o 

u 

>— 

OJ 

00 

■v.  U  • 

W) 

o 

c  « 

• 

• 

« 

o 

3S 

V/>  Q.T3 

0> 

C7>4.<  Z 

<\J 

*o 

H— 

o 

UJ 

O  "O 

C  )0  U 

1 

« 

0» 

00 

•M 

00 

CM  z  s: 

3 

O  S.  1. 

o 

•o  e 

• 

• 

• 

*o 

3 

U 

o  *■> 

at  o  <0 

00 

«  o 

3 

00 

O 

o  ••-  o 

O 

Q.  0) 

^•9  C 


0) 

^  01 

c 

o  o 

o  O  UJ  — 

u  V->  0^ 

TO 

u  o 

•r* 

CK 

<—  o 

o 

3 

C  • 

« 

*  • 

« 

^  sn 

.  O  1-  ■*■» 

•  *  SA  u  V- 

f— 

•*—  — » 

so 

o  ^ 

fs,  «  - 

lA  •»-  •*- 

u 

wio 

m  1^  ■«  c 

<  0-  «c 

C 

c  • 

•  ^ 

•  *0  • 

• 

O  o) 

^  o 

•r» 

CM 

z  0> 

0^  4-»  4-> 

r— 

o 

it$ 

u 

•o  •o 

u  c  >-> 

1 

•  00 

•  o  • 

• 

00 

o  <s>  s>  <v 

•  •  c  a>  a> 

“o  TO 

</) 

oa  TO 

oo  u 

£  (U  -M 

0)  w 

</) 

1.  k. 

T3  S- 

UJ  Q. 

lU  4.)  <0 

O  j. 

l/> 

O  O  00 

*Q  ID  c  O 

O  I— 

ID  ID 

lA 

.O  ^  wO 

O  QC  ^ 

01 

<A  f  O  O. 

i/> 

lO 

•e- 

•  ID  ^  • 

Q.  4-» 

>»  U  00  V) 

•  o 

.c 

•  • 

3  3 

O  O  +->  T3 

C 

JC  1-  < 

at 

t-  lA 

•  o 


u  *0 

to  o 
u 

I  I 


o 

v> 

O.O.'O'OZO  <U  3  t. 

o 

H-4 

O.  3  XJ 

«« 

O  C  ON 

1 

ID  • 

•o 

UUWU  (--Ottvo 

z 

ON  Q.  1.  1— 

00  OC  Z  ID  C 

1 

K 

u 

1. 

<a  <o  X  oe  c  o 

< 

1—  ID  ^ 

s 

o 

^ 

1 

0^  >« 

Of 

ID 

^9000  S»i-iZ 

•  • 

3  4->  i 

£ 

(/>  4-» 

1 

h-  ID 

O 

z  z  «  • 

oo 

04 

Q.‘»-  t-  O 

<  » 

0j<  -M 

• 

3 

o  o  ^  «c» 

z 

ECO 

oc 

>-  OJ 

1 

1  CX 

o. 

E— 

CMCMOUiX  >)«»  O  3 

oo 

O 

o  u. 

c 

1  to 

1 

lA 

E 

10 

1  1  o  <  V/)  z  t/i  z 

00 

z 

1 

o 

c 

1 

1- 

O 

c 

00<<->«  3CZ 

< 

1  1 

1 

O  E  4-* 

1 

0)  o 

u 

o 

OO  00  O  <0  U  0)  3 

z 

QJ 

4-> 

•1“  fc.  1— 

4*A 

o 

•f- 

f—  ^  Z  «/>  O 

t-  >T  W 

1 

-o  u 

•M  O  ct 

c  1- 

w 

vM 

u  o  01  04  «  m 

OJ  3 

or  or 

ID  4-1 

< 

•r-  QC 

u 

oooozu4^  cz_j_i 

oo 

4J  •*- 

4-» 

OJ 

4-»  lA  0) 

H- 

u  o 

TO 

c  <o<aao 

UJ 

01  f—  ID 

C 

Q.*|- 

•e-  1.  U 

O 

O. 

s:  TD 

< 
o 
00 
00 


u*0 


•••  U  •»“  (O  O  Q.  o;  3 
^0)0  •»-  TO  «/» 

•»-Q.Q.T0TDUCV> 

»r-  q;  i-  ^  i- 


CM  CO  ^  m  VO  rv  00  o>  o 


ID  O  < 

u  E  oc 

O  Oi  LU 

^  QO  Z 

Q. 

•  •  Qi 

f—  CM  UJ 


30 


ALWOS  SYSTEM  TOTAL  . - .  $75,865 

*(Does  not  inc lude  cost  of  Rem.  A/D  System  -  GFE'd  by  FAA's  TSC  group.) 


3.  SOFTWARE  CONFIGURATION 


SYSTEN  OVERVIEW 

The  Automatic  ^owcost  Weather  Observation  System  (ALWOS)  is  a 
real“time,  interrupt  driven,  mTcroprocessor  resident 
meterological  data  collection  and  reporting  system.  Running 
under  the  control  of  a  time  scheduling  executive,  ALWOS 
periodically  acquires  data  from  various  sensors  and  a  separate 
CPU,  collecting  and  processing  cloud  height  and  ceiling  data. 

It  processes  these  data,  performs  quality  control  checks,  and 
provides  communication  sources  to  transmit  and  display  the 
information. 

The  software  system  is  a  highly  modular,  flexible  system, 
making  extensive  use  of  tables  for  scheduling.  The  modularity 
and  tabling  structure  will  allow  the  system  to  accept  most  of 
the  existing  Inventory  and  newly  developed  sensors.  Modules 
may  be  easily  modified,  replaced  or  adde  for  tailored 
configurations . 

The  software  system  is  functionally  separated  into  nine 
components:  data  structure,  the  executive,  sensor  data 
collection,  sensor  data  conversion  and  processing,  keyboard 
processor,  data  display/communications,  quality  controller, 
maintenance,  and  accounting.  Each  of  these  components  is 
described  below. 

3.1  DATA  STRUCTURE 

Data  storage  and  executive  tables  are  defined  in  specific  areas 
of  Random  Access  Memory  (RAM)  and  Read  Only  Memory  (ROM). 

The  ROM  tables  are  defined  from  absolute  location  3C00H 
'ROMTBL*.  Tables  residing  there,  their  organization  and 
contents  are  defined  as  follows: 

RTA-  Timed  routine  jump  table.  An  expandable  table  Cu.'rently 
containing  42  entries.  Each  entry  requires  *  words,  and  is 
comprised  of  a  subroutine  call  followed  by  a  Jump  to  SCAN 
instruction.  There  is  one  entry  for  each  of  the  timed  modules 
currently  in  the  system.  The  table  is  used  to  transfer  control 
to  the  module  which  SCAN  determines  is  to  be  executed,  and 
return  control  to  SCAN  following  execution. 

SFKTBL-  Special  function  key  jump  table.  Table  of  28  entries 
corresponding  to  the  28  special  function  keys  on  the  keybo^.d. 
Eah  entry  requires  6  words  and  contains  a  subroutine  call,(  to 
respond  to  the  function  key)  followed  by  a  jump  to  KBENO 
(keyboard  interrupt  service  routine  entrv  point  to  restore 
interrupts  and  return  from  the  interrupt).  The  table  is 
organized  so  that  entries  sequentially  correspond  to  function 
key  ASCII  codes  (81H*9AH).  Currently  only  10  keys  are  used. 
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CTRTBL-  Cursor  control  table.  Table  of  7  entries  corresponding 
to  seven  cursor  control  functions:  left,  right,  down,  up,, 
erase,  carriage  return-line  feed,  and  home.  Each  entry 
requires  6  words  and  consists  of  a  subroutine  call  followed  by 
a  jump  to  KBENO,  (return  to  the  keyboard  interrupt  handler). 

DETBL-  Data  entry  mode  table.  This  table  is  an  expandable 
table  currently  consisting  of  3  entries  corresponding  to  3 
keyboard  input  modes.  Each  entry  is  6  words  long,  consisting 
of  a  subroutine  call  followed  by  a  jump  to  KBENO,  (return  to 
keyboard  interrupt  handler).  An  input  mode  software  flag  word, 
'KYMODE',  may  be  set  (0,1  2,3)  and  used  by  the  keyboard 
interrupt  handler  to  dispatch  through  this  table  for  data 
input.  KYM0DE=0  is  the  normal  mode  and  does  not  use  this 
table,  data  and  text  keys  are  only  echoed  by  the  interrupt 
handler.  KYM0DE=1  is  currently  used  to  set  the  real-time 
clock,  (subroutine  'STDATA'),  modes  2  and  3  are  not  used. 

JTBL-  Programmable  Interrupt  Controller  interrupt  vector  jump 
table.  This  table  is  absolutely  defined  beginning  at  3FC0H. 

It  contains  8  entries,  each  4  bytes  long  corresponding  to  the  8 
hardware  interrupt  levels.  Interrupts  are  hardware  vectored  to 
the  appropiate  level  entry  in  the  table.  Each  entry  consists 
of  a  jump  instruction  (jump  to  the  interrupt  service  routine) 
followed  by  a  no-operation  instruction  to  occupy  the  4th  byte. 

A  designated  block  of  RAM  memory  is  defined  at  7200H.  This 
expandable  block  is  currently  394H  words  long,  and  is  used  for 
all  system  storage  with  the  exception  of  some  temporary 
internal  storage  required  by  certain  modules.  Volatile  system 
tables  and  all  data  buffers  required  by  the  system  are  defined 
here.  Data  buffers  will  be  described  as  they  are  referenced  by 
individual  modules. 

TTA-  Scheduled  module  time  table.  This  expandable  table 
currently  contains  42  entries.  Each  entry  requires  6  words. 

The  table  is  organized  to  correspond  directly  to  the  timed 
routine  jump  table  (RTA)  in  ROM.  Each  entry  contains  month, 
day,  hour,  minute,  second,  and  a  year  flag.  The  entry 
specifies  the  exact  time  the  corresponding  routine  in  the  RTA 
table  is  to  be  executed  by  SCAN.  The  times  are  cleared  and 
must  be  reset  following  each  execution  of  the  routine. 

3.2  EXECUTIVE 

The  exe  utive  which  controls  the  ALWOS  operation  consists  of 
three  functional  components:  initialization/restart-recovery, 
interrupt  handlers,  and  module  execution  controller  (SCAN). 

3.2.1  INITIALIZATION/RESTART-RECOVERY 

During  initialization,  aut  matic  recovery  following  a  power 
failure,  or  after  resetting  the  real-time  clock,  the  following 
functions  are  performed  in  module  'INIT':  all  data  areas  in 
volatile  memory  (RAM)  are  cleared;  the  interrupt  controller, 

CPU  stack,  video-ram,  keyboard,  real-time  cl''c<,  event  sensor 
port,  and  remote  A/D's  are  initialized;  the  video-ram  display 
area  is  cleared;  the  real-time  clock  is  started  and  the 
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power-up  time  recorded;  site  dependent  variables  are  defined;  a 
block  of  buffers  in  RAM  used  to  form  averages  by  the  various 
processing  programs  is  initialized  to  OFFH;  modules  that  are  to 
be  executed  periodically  by  SCAN  are  initially  scheduled  for 
execution  by  inserting  the  execution  times  in  the  'TTA'  table; 
int  rrupts  are  enabled  to  start  the  data  collection  functions; 
and  CPU  control  is  transferred  to  the  execution  controller 
(SCAN).  The  'INIT'  module  is  an  absolute  module  starting  at 
location  0. 

3.2.2  INTERRUPT  HANDLERS 

The  interrupt  handler  section  of  the  executive  reacts  to 
hardware  interrupts  from  the  system  peripherals.  The 
Programmable  Interrupt  Controller  directs  CPU  control  to  a 
specified  memory  location  determined  by  the  interrupt  level 
(0-7).  The  predefined  locations  in  'JTBL'  contain  instructions 
which  vector  CPU  control  to  the  appropiate  interrupt  service 
module  . 

The  system  currently  accepts  interrupt  levels  2,  (keyboard);  3, 
(serial  characters  received  from  ceilometer  CPU  card);  4, 
(remote  A/D  #1);  5,  (remote  A/D  #2);  6,  (real-time  clock)  ;  and 
7,  (low-voltage  detect).  Each  interrupt  handler  (except  level 
7)  independently  saves  and  restores  the  state  of  the  system 
while  servicing  an  interrupt  and  enables  interrupts  following 
execution.  Level  7  interrupts,  or  low  voltage  detections, 
force  the  system  to  halt  execution  before  erratic  system 
behaviour  can  begin.  Interrupts  occurring  at  levels  other  than 
those  specified  above  are  handled  by  an  interrupt  error  service 
routine. 

Keyboard-  The  keyboard  interrupt  handler  ,'KEY'.  reads  and 
identifies  each  keystroke  and  responds  by  either  scheduling  a 
module  for  execution,  calling  a  subroutine,  or  performing  a 
specific  function.  The  response  depends  on  the  hexidecimal 
code  gene  ated  by  the  key  and  the  keyboard  input  mode  selected 
at  the  time  of  the  interrupt.  ROM  tables  'SFKTBL',  'CTRTBL', 
and  'DETBl'  are  used  to  determine  the  proper  response  to  the 
various  key  codes.  The  keyboard  input  mode  causes  a  routine 
called  in  table  'DETBL'  to  be  executed  for  data  and  text  keys, 
special  function  keys  cause  the  appropiate  routine  in  'SFKTBL' 
to  b-  executed  and  the  cursor  cont  'ol  keys  are  handled  through 
table  'CTRTBL'.  Selection  of  which  routine,  in  the  proper 
table,  to  execute  is  based  on  an  offset  into  the  table 
determined  by  the  hexidecimal  code  generated  by  each  key. 

Ceilometer  Characters-  For  each  character  that  is  received  over 
the  serial  input  port,  a  level  3  interrupt  is  generated. 
"CEILIN"  handles  the  ceilometer  message  input  character 
interrupts  then  reads  and  stores  the  ceilometer  message  in  RAM 
buffer  'CEILUP'.  After  receiving  the  end  of  message  character, 
"CEILIN"  schedules  "CEILMO"  for  execution  to  move  the 
ceilometer  message  from  the  interrupt  buf f er ( CE I LUP )  to  the 
processing  buffer(CEILCU)  . 

Remote  A/D  #1  and  #2-  For  each  interrupt  the  A/D  handlers  read 
the  data  from  ports  A  and  B,  identify  the  channe 1 ( 0- 1 5 ) ,  store 
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the  data  in  a  cycl  ng  buffer  and  reset  the  interrupt  control. 
This  is  a  continuous  process,  running  at  the  conversion  speed 
of  the  remote  A/D's.  Remote  A/D  #1  interrupt  handler,  'ADEXT', 
stores  data  in  RAM  buffer  'RADTB'.  The  A/D  #2  handler, 

'AD2EX',  uses  RAM  buffer  'RAD2B‘.  Each  buffer  is  32  words 
long,  with  2  sequential  8-bit  words  used  for  each  A/D  channel 
of  data.  The  most  significant  4  bits  are  a  channel  number, 
(0-15),  and  the  least  significant  12  bits  contain  the  digitized 
voltage  (1.221  mi  1 1  ivoT  s/bit) . 

Real-time  clock-  The  R/T  clock  interrupt  handler,  'RTC',  is 
executed  once/second.  It  reads  and  saves  the  clock  time, 
verifys  that  the  clock  has  incremented,  and  calls  a  subroutine 
to  display  the  new  time.  Clock  time  is  stored  in  a  5  byte  RAM 
buffer,  'CMT',  ( month , day , hour ,mi nu te , second ) ,  and  displayed  by 
subroutine  'DISCMT'.  The  subroutine  also  stores  the  ASCII 
equivalents  (MM/DD)  in  'DATASC',(5  bytes),  and  (HHMM)  in 
•TIMASC '  ,  (4  bytes)  . 

Low-voltage  detect-  A  level  7  interrupt  is  generated  whenever 
a  low  voltage  condition  is  detected  and  forces  the  CPU  to 
execute  a  HALT  instruction  and  cease  operation.  When  power  is 
restored  the  system  will  execute  a  complete  re-initialization 
before  normal  operation  is  begun. 

Interrupt  errors-  The  interrupt  error  handler,  'INTERR', 
handles  interrupts  at  any  other  level  (0,1).  These  result  in 
an  error  message  indicating  the  interrupting  level.  The 
interr(/pt  is  cleared  and  system  execution  continues  normally. 

3.2.3  MODULE  EXECUTION  CONTROLLER  (SCAN) 

The  SCAN  function  of  the  executive  is  active  when  no 
initialization,  data  processing  or  interrupt  ha  iling  is 
occurring.  This  function  activates  all  timed  modules  in  the 
system.  It  is  activated  during  initialization  and  continues  to 
cycle  each  second,  nterrupted  only  to  execute  a  timed  out 
module  or  for  hardware  interrupt  service.  SCAN  interrogates  a 
table  of  start  times  ,'TTA’,  associated  with  all  time  dependent 
modules.  The  modules  are  priority  ordered  to  assure  the 
highest  priority  module  is  executed  first.  The  start  time  for 
each  module  is  compared  to  the  current  clock  time  until  a 
greater-than  or  equal-to  match  ^s  found.  CPU  control  is  then 
transferred  to  this  module  through  ROM  table  'RTA',  and  its 
st^rt  time  is  removed  from  the  SCAN  table.  Following  module 
execution,  the  module  is  responsible  for  rescheduling  itself  by 
inserting  a  new  start  time  in  the  SCAN  table.  CPU  control  then 
returns  to  SCAN  and  the  scanning  process  continues  from  the 
beginning  of  the  SCAN  tabie.  If  during  a  one  second  scan,  the 
scanning  process  reaches  the  end  of  the  SCAN  table,  control  is 
passed  to  an  idle  timer,  which  displays,  at  the  beginning  of 
the  next  second,  the  percentage  of  time  th’t  the  system  was 
idle.  The  next  one  second  real-time  clock  interrupt  causes 
control  to  restart  the  SCAN  sequence. 

3.3.  SENSOR  DATA  COLLECTION 

Sensor  data  is  collected  using  the  external  A/D  interrupt 


handlers,  interrogation  of  the  internal  A/D,  'ADDATA',  and 
common icat ion  with  the  ceilometer  CPU  through  external  serial 
I/O  using  character  interrupts.  A  module,  'XADT',  is  executed 
each  second  which  checks  reference  voltages  for  both  remote 
A/D's  and  transfers  an  A/D  buffer  of  data  (16  channels  from  one 
of  the  A/D's)  into  a  1  second  raw  data  buffer  in  RAM,  ('ADTBL', 
32  words).  These  input  data  are  used  as  the  1  second  samples 
to  be  processed  over  the  next  second.  Pressure  data  are 
obtained  from  the  internal  A/0  through  interrogation  by  the 
scheduled  pressure  conversion  modules  at  a  10  second  rate. 
Approximately  every  four  minutes,  the  processed  ceilometer 
message  is  received  from  the  ceilometer  CPU  card  and  placed  in 
buffer  'CEILCU'  for  processing.  The  message  is  prepared  by  the 
ceilometer  CPU  operating  independently  of  the  main  CPU. 

3.4.  SENSOR  DATA  CONVERSION  AND  PROCESSING 


Conversion  and  processing  of  data  occurs  in  a  series  of 
scheduled  modules  for  each  parameter.  The  modularity  of  the 
system  is  preserved  in  most  cases  by  validating  and  converting 
data  to  sensor  independent  units  in  one  module  and  performing 
the  proc  ssing  algorithm  in  seperate  modules.  Each  parameter 
is  processed  by  a  module  or  group  of  modules.  The  modules  are 
scheduled  to  execute  at  intervals  required  by  the  parameters 
algorithm.  The  following  table  lists  each  module  by  name  and 
function,  specifies  its  primary  outputs  in  RAM,  and  any  special 
scheduling  considerations. 

XADT-Remote  A/O's  self-checking  and  acquisition. 

Execution-  1/second  prior  to  any  other  processing  module. 

Outputs-  'ADTBL',  buffer  containing  32  words.  (16  channels 
of  data,  bits  0-3*  channel  number  (0-15),  bits  4-15=  digitized 
voltage,  1.221  millivolts/bit). 

Contents  of  A/D  channels  for  remote  A/D  #1  and  #2. 


Channel  #  Contents 


0  Temperature 

1  Dew  Point 

2  Visibility  +log  voltage 

3  Visibility  -log  voltage 

4  Wind  Speed 

5  Wind  Direction,  Tap  A  voltage 

6  Wind  0 i rect ion.  Tap  B  voltage 

7  Wind  Direction,  Tap  C  voltage 

8  5v  Wind  Direction  reference,  nominal  5.0vdc 

9  Temperature  reference,  nominal  3.219vdc 

10  Dew  Point  reference,  nominal  2.404vdc 

11  19v  reference  for  multiplexer,  nominal  2.5vdc 

12  5v  power  supply,  nominal  2.5vdc 

13  +/-15V  reference,  nominal  l.Ovdc 

14  Hoffman  box  cooling  fan  sensor 

15  Ground  reference 


WS-  Wind  speed  acquisition  and  processing. 

Execution-  1/second. 

Output^-  'WSlAVG'-l  word,  wind  speed  1  min.  average  (knots). 


35 


r 


'WSCUR'-  1  word,  current  wind  speed  (knots). 

'WSIASC'-  5  word  buffer,  1  minute  average  wind  speed 
(ASCII,  knots). 

WD-  Wind  direction  acquisition. 

Execution-  1/second. 

Outputs-  'WDIAVG'-  1  word,  current  running  1  minute  wind 
direction  average  (degrees,  scaled  255/360). 

TUNDER-  Event  sensor  acquisition  and  thunderstorm  detection. 
Execution-  1/second  before  'LITEN*  or  'PRECIP'. 

Outputs-  'EVENT'-  1  word,  event  sensor  word  where: 
bit  0  1  2  3  4  5  6  7 

1  ZR  T  R  1  1  1  D/N 

Bit=l  for  ZR,T,R  indicates  event  present 
(Bit  #7  :  0=Day,  l=Night) 

Bits  0,4, 5, 6  not  used. 

'TUNFLG'-  1  word,  flag  indicating  presence  or  absence 
of  lightning  activity  and  timing  elapsed  since  last  strike. 

TMP-  Temperature  acquisition,  quality  control  and  conversion. 
Execution-  1/second. 

Outputs-  'TIAVG'-  1  word,  current  1  minute  temperature 
average  (op.). 

'TMPCUR'  1  word,  current  temperature  (op.). 

'TlASC'-  5  word  buffer,  current  1  minute  temperature 
average  (ASCII  op ,  . 

'TMPPLG'-  1  word,  temperature  error  flag. 

OPT-  Dew  point  acquisition,  quality  control  and  conversion. 
Execution-  1/second. 

Outputs-  'OPIAVG'-  1  word,  current  1  minute  dew  point 
average  ( op  . ) . 

'DPTCUR'-  1  word,  current  dew  point  (op.  . 

'DPIASC-  5  word  buffer,  current  1  minute  dew  point 
average  f ASC II  op .  . 

'DPIPLG'-  1  word,  dew  point  error  flag. 

CALINT-  Pressure  sensors  calibration  check. 

Execution-  Each  10  seconds. 

Output-  Console  message  if  calibration  bad. 

Calibration  data  is  acquired  by  'CALINT'  from  the  internal 
A/0,  Intel  SBC  711  analog  input  board,  through  subroutine 
'ADDATA'.  It  reads  the  calibration  voltage,  (nominal  3.333v) 
from  channel  13  of  the  A/D,  (12  bits,  1.221  millivolts/bit). 

PRSAQl-  Pressure  sensor  #1  and  offset  #1  acquisition  and 
conversion. 

Execution-  Each  10  seconds. 

Outputs-  Entry  in  'PRSlOF',  12  word  buffer  of  converted  10 
second  pressure  readings  (16  bits  per  data  entry  in  in.  of  Hg.). 

Data  is  acquired  through  subroutine  'ADDATA',  pressure 
sensor  #1  read  on  channel  3,  (12  bits),  offset  voltage  on 
channel  15  (12  bits),  each  has  a  resolution  of  1.221 
mi  1 1 i volts/bit . 

PRSAQ2-  Pressure  sensor  #2  and  offset  #2  acquisition  and 
conversion . 
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Execution-  Each  10  seconds. 

Outputs-  Entry  in  'PRS20F‘,  12  word  buffer  of  converted  10 
second  pressure  readings  (16  bits  per  data  entry  in  in.  of  Hg.) 

Data  read  by  subroutine  'ADOATA*,  pressure  sensor  #2  on 
channel  4,  (12  bits),  offset  voltage  on  channel  14,  (12  bits), 
1.221  millivolts/bit  for  each. 

VISACQ-  Acquisition,  quality  control  and  conversion  of 
Visibility. 

Execution-  Each  10  seconds. 

Outputs-  Entry  in  'VISABF',  12  word  buffer  of  10  second 
visibilities,  (16  bits  per  entry). 

'VIZNO'-  1  word  visibility  noise  counter. 

TEMP-  Temperature  processing. 

Execution-  1/minute  after  'TMP'. 

Outputs- '  T5AVG ' -  1  word,  5  minute  temperature  average(OF.) 
'TMPMAX'-  1  word,  5  minute  average  temperature  maximum 
'TMPMIN'-  1  word,  5  minute  average  temperature  minimum 
'T5ASC'-  5  word  buffer,  5  minute  temperature  average 
(ASCII  OF.). 

DEWPT-  Dew  point  processing. 

Execution-  1/minute  after  'TEMP'  and  "DPT'. 

Outputs-  'DP5AVG'-  1  word,  5  minute  dew  point  average 
(OF.). 

'0P5ASC'-  5  word  buffer,  5  minute  dew  point  average 
(ASCII  OF.). 

'DPTC'-  1  word,  dew  point  error  count. 

WNDSPD-  10  minute  wind  speed  processing. 

Execution-  1/minute  after  'WS'. 

Outputs-  'WSIOAV'-  1  word,  10  minute  wind  speed  average 
(knots ) . 

'WSIOAS'-  5  word  buffer,  10  minute  wind  speed  average 
(ASCII  knots). 

GUST-  determine  10  minute  maximum  wind  speed  gust  and  peak  wind 
Execution-  1/minute  after  'WNDSPD'. 

Outputs-  'GSTCUR'-  1  word,  current  maximum  gust  (knots). 
'GSTASC'-  5  word  buffer,  current  maximum  gust  (ASCII 

knots ) . 

'PKWASC'-  5  word  buffer,  current  peak  wind  (ASCII 

knots ) . 

WNDDIR-  1  minute  wind  direction  quality  control  and  processing. 
Execution-  1/minute  after  'WD'  and  'WNDSPD'. 

Outputs- ' WD lAVG '- 1  word,l  minute  wind  direction  average(o) 
'WDIASC-  5  word  buffer,  1  minute  wind  direction 
average  (ASCII  lO's  of  o). 

'WDMASC-  5  word  buffer,  1  minute  magnetic  wind 
direction  (ASCII  lO's  of  o). 

'WDCNT'-  wind  direction  error  count. 

PRSPCl-  Station  pressure  and  altimeter  setting  calculations. 
Execution-  1/minute  after  'PRSAQl'  and  'PRSAQ2'. 

Outputs- '  PRIASC '  5  word  buffer,  ASCII  station  press.  #1  in.Hg 


'PR2ASC'-  5  word  buffer,  ASCII  station  pressure  #2 
(inches  Hg . ) • 

'ALTASC-  5  word  buffer,  ASCII  altimeter  setting. 
'PRICUR'-  2  words,  current  station  pressure  (inches 

Hg. ) . 

'PR2CUR'-  2  words,  current  station  pressure  #2  (inches 

Hg.)  . 

VIZ-  Sensor  equivalent  visibility  (SEV)  processing. 

Execution-  1/minute  after  'VISACQ'. 

Outputs-  'VIZCUR'-  2  words,  current  SEV  (miles). 

'VIZER'-  1  word,  count  of  visibility  failures. 

VZAS'-  1  word,  visibility  table  offset  for  ceilometer 

CPU. 

'VIZOFF'-  1  word,  visibility  table  offset  for  'VOICE' 

output . 

'VIZASC'-  4  word  buffer,  current  10  minute  average  SEV 
(ASCII  miles). 

'PVASC'-  16  word  buffer,  visibility  variability 
remark,  (ASCII),  word  1  of  buffer=  #  ASCII  characters  in  remark. 

VISIBILITY  FLAGS  -  Two  visibility  flags  are  passed  to 
the  Ceilometer  CPU  card  in  parallel  through  port  E5H  on  the 
main  CPU  card: 

bit  6  =  1  means  that  visibility  is  missing 
bit  7  =  1  means  that  visibility  value  is  less  than 
or  equal  to  1.5  miles,  (bit  7=0  means  v i s i b . greater  than  1.5 
miles)  If  visibility  is  missing,  then  the  ceilometer  processed 
output  will  be  reported  missing.  The  ceilometer  card  uses  the 
visibility  value  less  than  or  equal  to  1.5  miles  to  determine 
possible  obscuration  conditions. 

LITEN-  Thunderstorm  event  processing. 

Execution-  1/minute  after  'TUNDER'. 

Outputs-  'TRMASC-  7  word  buffer,  thunderstorm  beginning  or 
ending  remark  (ASCII). 

PRECIP-  Precipitation  event  processing. 

Execution-  1/minute  after  'TUNDER*. 

Outputs-  'RASC'-  7  word  buffer,  precipitation  beginning  or 
ending  remarks  buffer.  (ASCII). 

3.5.  KEYBOARD  PROCESSOR 

The  keyboard  processor  handles  all  manual  entry  of  standard  and 
special  function  keys.  Software  components  are  scheduled  or 
called  as  subroutines  by  the  keyboard  interrupt  handler  to 
provide  special  displays  for  maintenance  and  accounting,  clear 
displays,  set  the  real-time  clock,  initialize  the  system,  and 
respond  to  other  specific  function  keys.  Subroutines  called  by 
•KEY’  through  ROM  tables  'SFKTBL',  'CTRTBL',  and  'DETBL'  to 
handle  the  keyboard  processing  are  listed  and  discussed  in  the 
'ROMTBL'  module  listing. 

3.6.  DATA  DISPLAY/COMMUNICATIONS 

The  display  processor  functions  are  performed  by  several 
modules  which  handle  the  assembly  and  output  of  information  to 
the  CRT's  and  transmission  of  separate  messages  to  cassette, 
telephone  and  voice  outputs.  Modules  are  scheduled  at  regular 
intervals  for  display  and  transmission,  or  on  demand  as  the 


result  of  special  function  keystrokes  for  the  maintenance  and 
accounting  displays.  The  following  table  lists  normal  output 
modules  by  name  and  function,  lists  primary  input  and  output, 
and  special  scheduling  considerations. 

CRTOUT-  Assemble  and  output  1  minute  message  data  to  the  remote 
CRT  display. 

Execution-  1/minute  following  all  processing  modules. 

Input-  ASCII  buffers  in  RAM  containing  the  processed  data 
to  be  output: 

'DATASC,  'TIMASC,  'RASC.  'TRMASC,  ’VIZASC,  'T5ASC' 
•DP5ASC’,  ‘WDIASC,  'WSIASC,  '6STASC'.  'ALTASC,  and  'CEILCU'. 

Output-  'HDRBUF'-  23  word  buffer  containing  station  header 
and  time  of  message  (ASCII).  First  byte  of  buffer  contains  the 
#  of  ASCII  characters  (bytes)  in  the  buffer  ( hexidec imal )  . 

'RBCASC'-  20  word  buffer  containing  the  ceiling 
remarks  generated  by  the  Ceilometer  CPU,  (ASCII).  First  byte=  # 
ASCII  bytes  in  buffer,  (hexadecimal). 

'CRTBUF'-  60  word  buffer  containing  the  assembled  data 
message,  a  composite  of  ASCII  input  buffers,  (ASCII).  First 
byte=  #  ASCII  bytes  ( hex i dec ima 1 ) . 

Contents  of  the  output  buffers  are  also  output  to  the 
Output  board  for  display  on  the  remote  CRT. 

VOICE-  Output  1  minute  message  to  the  Voice  output  board  in  the 
form  of  vocabulary  addresses  for  spoken  output. 

Execution-  1/minute  after  'CRTOUT*. 

Input-  ASCII  buffers  in  RAM  containing  data  to  be  broadcast 

ASCII  buffers:  'T5ASC',  'DPSASC,  'WSIASC,  'WDMASC, 
•GSTASC.  ALTASC.  'TRMASC,  'RASC,  'TIMASC,  'RBCASC,  and 
'VIZOFF'-  1  word  offset  pointer  to  the  visibility  in  'VSLST', 
the  visibility  vocabulary  table. 

Output-  vocabulary  addresses  to  the  speech  output  board 
hardware . 

CASOUT-  Output  1  minute  message  to  the  cassette  and  telephone 
line. 

Execution-  Each  19  and  20  minutes  after  'CRTOUT'. 

Input-  ASCII  message  buffers:  'HDRBUF',  'CRTBUF',  and 
'RBCASC ' . 

Output-  ASCII  characters  to  the  FIFO  on  the  Output  board. 

'FALASC'-  5  word  buffer,  the  error  status  word  (ASCII) 

3.7.  QUALITY  CONTROL 

Quality  control  checks  are  applied  at  two  levels.  During  the 
data  acquisition,  on  reference  and  calibration  voltages,  as  a 
self-ch  uk  of  the  equipment,  and  during  conversion  and 
processing  phases  for  integrity,  range  extremes,  and  parameter 
rate  of  change.  All  failures  are  recorded  in  the  accounting 
section  and  appropriate  indications  are  given  in  the  form  of 
error  messages  and  missing  data  in  the  system  outputs. 

An  error  status  word  buffer,  'FALASC',  is  generated  in 
'CASOUT'  and  output  to  the  cassette  and  telephone,  (see  3.9 
ACCOUNTING. 
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3.8,  MAINTENANCE 


Data  input  into  the  system  may  be  monitored  at  the  raw  data  and 
processed  data  levels  through  a  maintenance  display  available 
at  the  system  console  initiated  by  a  special  function  key.  The 
display  shows  the  digitized  voltages  from  the  remote  and 
internal  A/D's  as  well  as  the  processed  data.  The  display  may 
be  updated  at  a  1  or  5  second  rate  or  on  demand  from  the 
keyboard.  Input  data  from  either  remote  A/D  may  be  selected, 
via  the  keyboard. 

DISEXA-  Display  raw  input  data  on  the  console  CRT. 

Execution-  Selected  via  a  special  function  key,  once 
selected,  executes  once  per  second,  once  per  5  seconds  or  on 
demand.  Scheduled  for  execution  after  'XADT'. 

Input-  'AOTBL'-  32  word  buffer  of  remote  A/D  data. 

Channels  3,4,13,14,15  of  the  internal  A/D,  read  with 

•ADDATA'  . 

'UAD'-  1  word  indicating  the  remote  A/D  being  used , 
1=A/D  #1 ,  2=A/D  #2, 

Output-  Formatted  display  on  the  console  CRT  containing  all 
the  raw  data  input  used  by  the  system. 

MINDSY-  Display  1  minute  output  data  on  the  console  CRT  for 
maintenance  or  monitor  purposes. 

Execution-  Selected  via  a  special  keyboard  code, 
control-shift-/\/.  When  selected,  the  module  is  scheduled  to 
execute  1/minute  after  'CRTOUT'. 

Input-  ASCII  data  buffers:  'TIASC,  'DPIASC,  'WSIASC, 
'WDIASC,  'VIZASC,  'PRIASC,  'PR2ASC',  'RBCASC,  'CRTBUF',  and 
•PVASC  '  . 

Output-  The  data  from  the  ASCII  buffers  is  formatted  and 
stored  in  Video-ram. 

3.9.  ACCOUNTING 

The  accounting  software  retains,  and  can  display  on  demand,  a 
history,  since  the  last  0  hour,  of  the  system  status.  The 
latest  power-up  time  and  the  number  of  failures  for  each  sensor 
and  all  A/D's  in  the  last  hour  and  for  the  last  24  hour  period 
is  available  at  all  times  in  the  system.  A  system  status  word, 
with  one  bit  assigned  to  each  sensor  or  A/D  is  extracted  from 
the  hour  accounting  data  at  20  minute  intervals,  and  is  output 
as  part  of  the  cassette  and  telephone  message.  This  status 
word  indicates  only  recent  and  current  failures  within  the 
system , 

'FALASC'-  A  5  word  buffer  containing  the  ASCII 
representation  of  the  error  status  word.  The  error  word  is 
formed  from  1-bit  associations  to  the  error  counts  in  buffer 
'TMPCNT',  (see  ERRHR).  Bit  0=  temperature,...,  bit  11=  remote 
A/D  #2.  Each  non-zero  bit  indicates  a  corresponding  non-zero 
error  count  for  the  sensor/device  in  'TMPCNT'. 

ERRHR-  Accumulate  1  hour  and  since  hour  0  counts  of  sensor 
errors  and  device  failures  in  the  system. 

Execution-  1/hour  after  all  collection  and  processing 
modules. 
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Input-  'TMPCNT 
error  counts. 

Word 

1 - 

2 

3 

4 

5 

6 

7 

8 

9 

10 
1 1 

12-16 

■TMP24'- 

since  last  hour  0. 
‘TMPCNT ■ . 


'-  16  word  buffer  of  1  hour  sensor  and  device 

Sensor/Device 

Temperature 

Dew  point 

Wind  speed 

Wind  direction 

Pressure  sensor  #1 

Pressure  sensor  #2 

Calibration  voltage  check 

Visibility  sensor 

Internal  A/D  timeout  check 

Remote  A/D  #1  reference  voltages 

Remote  A/D  #2  reference  voltages 

Spares . 

16  word  buffer  of  summations  of  failures 
The  ordering  of  the  buffer  is  identical  to 


ERRDSP-  display  accounting  data  on  console  CRT. 

Execution-  On  demand  by  a  special  function  key. 

Input-  'TMPCNT'-  16  word  buffer  of  1  hour  failure  counts. 
'TMP24'-  16  word  buffer  of  failure  counts  since  the 
last  hour  0.  » 

Outputs-  A  formatted  display  on  the  console  CRT  of  error 
counts  for  the  sensors  and  devices  supplying  input  to  the 
system. 

3.10.  UTILITIES 


The  system  uses  a  number  of  general  purpose  utility  routines 
which  are  called  as  subroutines  by  many  of  the  modules  in  the 
system.  Following  is  a  list  and  brief  description  of  utilities 
in  the  software  system. 

SCHED  Schedule  a  module  for  execution  by  inserting  the 
current  RTC  time  plus  the  indicated  offset  in  the  proper  entry 
i n  ROM  table  ' TTA ‘ . 

SCHIM-  Schedule  a  module  for  execution  on  the  next  whole 
minute. 

SCHIO-  Schedule  a  module  for  execution  at  the  next  whole  10 
second  interval. 

DISMSG-  Output  the  designated  ASCII  message  to  the  message 
display  area  of  video-ram. 

SCROLL-  Scroll  messages  in  the  message  display  area  of 
video-ram  and  blank  the  last  line. 

MCURS-  Move  the  video-ram  cursor  as  indicated. 

ECHO-  Echo  an  ASCII  character  to  video-ram  and  move  the 
cursor . 

DELETE-  Delete  the  character  to  the  left  of  the  video-ram 
cursor  and  move  the  cursor  left  one  position. 

MOVBYT-  Move  a  number  of  bytes  from  one  starting  location 
to  another.  Move  the  last  source  byte  first  to  allow 
overlaying  blocks. 

BINASD-  Convert  a  16-bit  binary  value  to  5  byte  ASCII 
decimal,  left  justified  with  leading  zeros  suppressed. 

ASHEX-  Convert  5  byte  ASCII  decimal  to  a  16  bit  hexidecimal 
value. 
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CDROH-  Compare  two  CPU  register  pairs  for  greater-than , 
less-than,  or  equal  . 

SHFTLD-  Shift  a  16  bit  CPU  register  pair  left  the  specified 
number  of  bits. 

DVI-  Divide  a  16  bit  dividend  by  an  8  bit  divisor. 

PUSHWD-  Push  the  designated  block  of  words  down  1  byte, 
last  byte  first.  The  last  word  is  overwritten. 

PUSHDN-  Push  the  designated  block  of  16  bit  values  down  1 
value.  The  last  2  bytes  are  overwritten. 

AVG-  Form  the  average  of  the  indicated  block  of  words. 

AV6WD-  Form  the  average  of  the  indicated  block  of  16  bit 
values . 

DIV-  Divide  a  16  bit  dividend  by  a  16  bit  divisor. 

MULT-  Multiply  a  16  bit  multiplicand  by  a  16  bit  multiplier 

SUBT-  Subtract  two  CPU  register  pairs  (16  bits  each) 
producing  an  absolute  difference  and  indicating  the  proper  sign 

COMP-  Form  the  I's  complement  of  a  16  bit  CPU  register  pair 

STANUM-  Store  a  constant  in  a  specified  number  of 
sequential  RAM  locations. 

CRT-  Transfer  a  string  of  ASCII  characters  into  display 
memory.  String  is  terminated  by  a  null  (0)  character. 

SHFTRD-  Shift  a  CPU  register  pair  right  a  given  number  of 
bits. 

MOUT-  Store  4  ASCII  spaces  and  an  ASCII  'M*  in  the 
designated  5  byte  buffer. 

3.11  MEMORY  ALLOCATION 

The  ALWOS  memory  configuration  is  shown  in  figure  3-1.  This 
memory  space  does  not  include  the  memory  that  is  contained  on 
the  ceilometer  CPU  card.  Its  memory  is  accessed  independently 
of  the  main  system  memory  and  is  described  in  section  2.2. 1.2  - 
Ceilometer  CPU  Card. 


ALWOS  MEMORY  MAP 

CPU  KOM 


M»IM  CPU  POM 


tUPAViiOKi  POM 


StPPHHON  ROM 


'‘PtcoMprfp  peiep'ieo 


fNTBMPL  A/o  MPPPtMA 


ViPeO-RPM  /pt^YBPPPP  MPPPIU(> 


MPfN  CPU  PAM 


e^PANifCM  PAM 


(mPAM^IOM  PAM 


frPAusfOM  Pam 


3'tPAMSiON  RAM 
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FIG.  3-1 


3.12  SENSOR  ALGORITHMS 


The  sensor  algorithms  contained  in  this  section  are  described  through 
the  use  of  Program  Design  Language  (PDL).  PDL  is  an  English  language 
alternative  to  flowcharting  methods  in  describing  a  processing 
algorithm.  It  offers  a  set  of  shorthand  conventions  for  most  common 
flowchart  patterns,  such  as  branches  and  loops  of  various  kinds.  For 
example,  the  following  figure  can  be  replaced  by  its  PDL  equivalent 


PDL  equivalent: 

IF  END  OF  HOUR 

THEN  XMIT  HOURLY  MESSAGE 
ELSE  READ  NEXT  RECORD 

ENOIF 


Each  IF  statement  is  matched  against  a  corresponding  ENDIF  statement 
to  signify  the  end  of  a  test  condition.  Nesting  of  test  conditions  is 
also  allowed  .  Corresponding  indentations  of  the  matching  IF  and 
ENDIF  statements  facilitates  the  decoding  process.  The  "ELSE" 
statement  is  optional  if  it  means  simply  to  continue  on  to  the 
following  "ENDIF"  statement.  A  more  detailed  analysis  of  PDL  can  be 
found  in  several  of  the  structured  program  literature  but  is  probably 
not  necessary  to  understand  the  algorithms  presented  in  this  section. 
In  addition  to  POL,  a  hexadecimal  notation  is  also  used  to  describe 
the  bit  pattern  of  an  8-bit  byte.  Hexadecimal  or  "hex"  implies  that  a 
numerical  base  of  16  is  indicated  rather  than  decimal  or  binary  code. 
The  use  of  this  code  is  followed  by  the  letter  H.  The  equivalency 
between  binary,  decimal  and  hexadecimal  codes  is  shown  below.  Each 
hex  character  then  represents  four  bits  or  2  hex  characters  for  every 
8-bit  byte.  An  example  of  hex  code  would  be  3FH  which  is  equivalent 
to  0011  1111  in  binary  code.  The  hexadecimal  code  OFFH  or  FFH 
(leading  0  is  optional)  is  often  used  in  the  following  text  to 
represent  a  -1  for  flag  words. 


Binary 

"Too 

Decimal 
(5 - 

Hexadecimal 
- Q - 

Binary 

^nnsTT 

Decimal 
- 5 - 

Hexadecimal 
- 8 - 

0001 

1 

1 

1001 

9 

9 

0010 

2 

2 

1010 

10 

A 

001 1 

3 

3 

1011 

1 1 

B 

0100 

4 

4 

1100 

12 

C 

0101 

5 

5 

1101 

13 

D 

0110 

6 

6 

1110 

14 

E 

01  1 1 

7 

7 

nil 

15 

F 

other 

notations  used  in  this  section 

are : 

•  LT. 

=  Less  than 

.GT.  = 

Greater 

than 

•  LE. 

=  Less  than 

or  equal  to 

.GE.  = 

Greater 

than 

or  equal 

The  loud  and  visibility  algorithms  are  not  presented  in  this  section 
but  can  be  found  in  Appendices  A  and  B,  respectively. 


3.12.1  TEMPERATURE 

The  temperature  data  is  processed  by  subroutines  “TMP"  and  "TEMP". 
TMP 


Purpose:  TMP  performs  temperature  quality  control  and  averaging.  It 

is  called  once  every  10  seconds. 

Variable  Names: 

TMPFLG  -  ERROR  FLAG  (ERROR  =  -1) 

TIAVG  -  TEMPERATURE  1-  MIN  AVERAGE 
TMPCUR  -  CURRENT  TEMPERATURE 
TIASC  -  1-MIN  AVG  TEMP  ASCII  BUFFER 
TMPTBL  -  1-MIN  TEMPERATURE  STACK 

SCL  -  SUBROUTINE  TO  CONVERT  A/D  VOLTAGES  TO  TEMPERATURE 


Method : 


PUSH  DOWN  ONE-MINUTE  STACK 

GET  TEMPERATURE  VOLTAGE  FROM  RAM 

CONVERT  VOLTAGE  TO  TEMPERATURE  BY  CALLING  SCL 

IF  ((BEYOND  VOLTAGE  LIMITS)  .OR.  (TMP  .GT.  122  DEG.  F.).OR. 

.  (TMP.LT.  -58  DEG  F.)  .OR.  (1  MIN  DIFF  .GT.  6  DEG.  F.)) 

.  THEN  IF  (2N0  ERROR  IN  1  MINUTE) 

.  THEN  SET  ERROR  FLAG 

.  INCREMENT  ERROR  COUNT 

.  SET  DATA  NOT  AVAILABLE  (-1  IN  TMPCUR) 

.  SET  AVERAGE  NOT  AVAILABLE  (-1  IN  TIAVG) 

.  SET  ASCII  M  IN  AVERAGE  BUFFER 
ENDIF 

.  ELSE  IF  (1ST  ERROR  OR  LAST  MINUTE  MISSING) 

.  THEN  SET  DATA  NOT  AVAILABLE  (-1  IN  TMPCUR) 

.  SET  AVERAGE  NOT  AVAILABLE  (-1  IN  TIAVG) 

.  SET  ASCII  M  IN  AVERAGE  BUFFER 
.  ELSE  STORE  CURRENT  TEMPERATURE  IN  RAM 
.  STORE  CURRENT  TEMPERATURE  IN  STACK 
ENDIF 

IF  NOT  1  MIN  OF  GOOD  DATA 
.  THEN  SET  AVERAGE  NOT  AVAILABLE 
.  SET  ASCII  M  IN  AVERAGE  BUFFER 
.  ELSE  TAKE  SUM  OF  1-MIN  STACK 
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.  DIVIDE  TO  TAKE  AVERAGE 
.  STORE  AVERAGE  IN  RAM 
.  CONVERT  TO  ASCII  DECIMAL 
.  STORE  IN  ASCII  BUFFER 
.  IF  (ERROR  FLAG  .GT.O) 

.  .  THEN  RESET  ERROR  FLAG  TO  0 

.  ENDIF 

ENDIF 

ENDIF 

RESCHEDULE  IN  TEN  SECONDS 

RETURN 

END 

TEMP 


Purpose;  TEMP  calculates  the  five-minute  temperature  average  and 
running  maximum  and  minimum.  It  is  called  once  each  minute. 

Variable  Names: 


T5AVG  - 

5-MIN  TEMPERATURE  AVERAGE 

TIAVG  - 

1-MIN  TEMPERATURE  AVERAGE 

TMPMAX  - 

TEMPERATURE 

MAXIMUM 

TMPMIN  - 

TEMPERATURE 

MINIMUM 

T5ASC  - 

5-MIN  ASCII 

BUFFER 

T5TBL  - 

5-MIN  STACK 

TMPMN  - 

ROUTINE  NAME 

IN  SCAN  TABLE 

TMPC 

10-SEC  ERROR 

COUNT 

TMPCNT  - 

1-MIN  ERROR 

COUNT 

TMPOK  - 

TEMPERATURE 

OFFSET 

Method : 

PUSH  5-MINUTE  STACK  DOWN 
IF  (10-SEC  ERROR  COUNT. NE.O) 

THEN  INCREMENT  1-MIN  ERROR  COUNT 
ENDIF 

CLEAR  10-SEC  COUNT 

GET  1-MIN  AVERAGE 

STORE  AVERAGE  OR  OFFH  IN  STACK 

IF  (1-MIN  AV6  MISSING. OR. 1ST  4  MIN. OR. NOT  5  MIN  GOOD  DATA) 
THEN  SET  5-MIN  AVG  MISSING  (-1  IN  T5AVG) 

SET  ASCII  BUFFER  TO  M 
ELSE  TAKE  SUM  OF  5-MIN  STACK 

DIVIDE  TO  TAKE  5-MIN  AVERAGE 
STORE  AVERAGE  IN  T5AVG 
SUBTRACT  TEMPERATURE  OFFSET  (99) 

CONVERT  TO  ASCII  DECIMAL 
STORE  IN  ASCII  BUFFER 
UPDATE  MAXIMUM  AND  MINIMUM 

ENDIF 

RESCHEDULE  FOR  NEXT  MINUTE 

RETURN 

END 

ERROR  PROCESSING: 

IF  THE  10-SEC  ERROR  COUNT  IS  NON-ZERO,  THE 
1-MIN  ERROR  COUNT  IS  INCREMENTED.  IF  THE  5-MIN 
AVERAGE  IS  MISSING,  T5AVG  IS  SET  TO  -1, 

AND  THE  ASCII  BUFFER  T5ASC  IS  SET  TO  "M"  (missing). 
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3.122  DEW  POINT 

Dew  Point  data  is  processed  by  subroutines  “DPT"  and  "DEWPT". 

DPT 

Purpose:  DPT  performs  dew  point  quality  control  and  averaging.  It  is 

called  once  every  10  seconds. 


Variable 
ADTBL 
DPTSEC 
DPIAVG 
DP  lASC 
DPTCUR 
DPTTBL 
VLTMI N 
VLTMAX 
DPTOK 
DPTLST 
ER2FLG 
DPTC 
SCL 


Names : 

TABLE  OF  A/D  CHANNEL  VOLTAGES 

ROUTINE  NAME  IN  SCAN  TABLE 

1-MIN  AVERAGE 

1-MIN  AVG  ASCII  BUFFER 

CURRENT  DPT 

1-MIN  STACK 

VOLTAGE  MINIMUM 

VOLTAGE  MAXIMUM 

DPT  OFFSET 

OPT  1  MIN  AGO 

ERROR  FLAG  FOR  LAST  MINUTE 
ERROR  COUNT 

SUBROUTINE  TO  CONVERT  A/D  VOLTAGES  TO  TEMPERATURE  (or  DEW 
POINT  ) 


Method : 


PUSH  1-MINUTE  STACK  DOWN 

GET  VOLTAGE  FROM  RAM 

CONVERT  VOLTAGE  TO  DEW  POINT  BY  CALLING  SCL 

IF  ((TEMP  MISSING). OR. (VOLTAGE  LIMITS  EXCEEDED)  .OR  . 

(0P-TMP.GT.2)  .0R.(DP.LT.-40  DEG  F ) . OR  .  ( DP . GT  . +90  DEG  F) 
.0R.(1  MIN  DIFFERENCE  .GT. 6  DEG  F)) 

THEN  IF  (2N0  ERROR  IN  ONE  MINUTE) 

THEN  SET  ERROR  FLAG 
ENDIF 

INCREMENT  ERROR  COUNT 

SET  1-MIN  ERROR  FLAG  (ER2FLG) 

ENDIF 

IF(DP  T.GT.0.AND.DP-T.LE.2) 

THEN  SET  DP=T 

ENDIF 

IF  ((ERROR  FLAG  SET). OR. (1ST  10  SEC ) .OR . ( FOLLOWI NG  ERROR)) 
THEN  SET  DATA  NOT  AVAILABLE  (-1  IN  DPTCUR) 

ELSE  STORE  CURRENT  DATA  IN  RAM 

STORE  CURRENT  DATA  IN  1-MIN  STACK 

ENDIF 

IF((ERROR  FLAG  SET )  .  OR  .  ( DATA  MI  SSI NG )  OR  .  ( NOT  ONE 
MINUTE  OF  GOOD  DATA)) 

.  THEN  SET  AVERAGE  NOT  AVATLBLE  (-1  IN  DPIAVG) 

SET  ASCII  BUFFER  TO  ' 

.  ELSE  CALL  AVG  TO  TAKE  STACK  AVERAGE 
STORE  AVERAGE  IN  RAM 
CONVERT  TO  ASCII  DECIMAL 
STORE  IN  ASCII  BUFFER 
IF(ERROR  FLAG.GT.O) 

.  THEN  SET  ERROR  FLAG  TO  0 
ENDIF 

ENDIF 
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RESCHEDULE  IN  10  SECONDS 

RETURN 

END 

ERROR  PROCESSING: 

IF  THERE  ARE  TWO  ERRORS  OR  MORE  IN  ONE  MINUTE,  THE  ERROR  FLAG  IS 
SET,  AND  THE  ERROR  COUNT  IS  INCREMENTED.  IF  DATA  IS  NOT  AVAILABLE, 
THE  CURRENT  DPT  (DPTCUR)  AND  THE  1-MIN  AVERAGE  (DPIAVG)  ARE  SET  TO 
-1,  AND  THE  ASCII  BUFFER  IS  SET  TO  M  (MISSING). 

DEWPT 

Pu  pose:  DEWPT  calculates  the  five-minute  dew  point  average.  It  is 
called  once  each  minute. 

Var  able  Names : 

DP5AVG  -  5-MIN  DEW  POINT  AVERAGE 
DP5ASC  -  5-MIN  DEW  POINT  ASCII  BUFFER 
DPIAVG  -  1-MIN  DEW  POINT  AVERAGE 
DPTMN  -  ROUTINE  NAME  IN  SCAN  TABLE 
DP5TBL  -  5-MIN  STACK 
DPTC  -  10-SEC  ERROR  COUNT 
DPTCNT  -  1-MIN  ERROR  COUNT 
DPTOK  -  DPT  OFFSET 

Method  : 

PUSH  DOWN  5-MINUTE  STACK 
IF(10-SEC  ERROR  COUNT. NE.O) 

THEN  INCREMENT  1-MIN  ERROR  COUNT 
ENDIF 

CLEAR  10-SEC  ERROR  COUNT 
GET  1  MINUTE  AVERAGE 

STORE  AVERAGE  OR  -1  (OFFH)  IN  STACK  IF  ERROR  IS  L  TECTED 
IF(1-MIN  AVG  MISSING. OR.  1ST  4  MINUTES. OR. 

NOT  5  MIN  GOOD  DATA) 

THEN  SET  5-MIN  AVG  MISSING  (-1  IN  DP5AVG) 

SET  ASCII  BUFFER  TO  M 
ELSE  TAKE  SUM  OF  5-MN  STACK 

DIVIDE  TO  TAKE  5-MIN  AVERAGE 
STORE  5-MIN  AVERAGE  IN  RAM 
SUBTRACT  DEWPOINT  OFFSET  (97) 

CONVERT  TO  ASCII  DECIMAL 
STORE  IN  ASCII  BUFFER 

ENDIF 

RESCHEDULE  FOR  NEXT  MINUTE 

RETURN 

END 

ERROR  PROCESSING: 

IF  THE  5-MIN  AVERAGE  IS  MISSING,  DP5AVG  IS  SET  TO  -1,  AND 
THE  ASCII  BUFFER  IS  SET  TO  M.  IF  THE  10-SEC  ERROR  COUNT  IS 
NOT  ZERO,  THE  1-MIN  ERROR  COUNT  IS  INCREMENTED. 
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3.12.3  WIND  SPEED 


The  w  nd  speed  data  is  processed  by  subroutines  "WS"  and  “GUST". 


Purpose;  WS  penorms  wind  speed  quality  control  and  one-minute 

averaging.  It  is  called  once  each  second. 

Va r i a  1 1 e  Names : 

AD  BL  -  TABLE  OF  A/D  CHANNEL  VOLTAGES 

WSSEC  -  ROUTINE  NAME  IN  SCAN  TABLE 

WSFLG  -  ERROR  FLAG 

WSCNT  -  1-SEC  ERROR  COUNT 

WSIAVG  -  1  MIN  AVERAGE 

WSIASC  -  1-MIN  ASCII  BUFFER 

WSCUR  -  CURRENT  WIND  SPEED 

WSITBL  -  1-MINUTE  STACK 

VLTMIN  -  VOLTAGE  MINIMUM 

VLTMAX  -  VOLTAGE  MAXIMUM 

WSBIAS  -  BIAS  TO  WIND  SPEED 

Method: 

PUSH  1-MINUTE  STACK  DOWN 

GET  VOLTAGE  FROM  RAM 

CONVERT  VOLTAGE  TO  WIND  SPEED  (DIVIDE  BY  8.2) 

ADD  WIND  SPEED  BIAS 

IF(VOLTAGE  LIMITS  E XCEE DED  .  OR . WS  .GT . 1 25  KNOTS) 

THEN  SET  ERROR  FLAG 

INCREMENT  ERROR  COUNT 
SET  DATA  MISSING(=FFH) 

SET  AVERAGE  MISSING 
ELSE  STORE  CURRENT  WS 

STORE  CURRENT  WS  IN  1  MIN  STACK 
IF(ERROR  FLAG.GT.O.AND.5  SEC  OF  GOOD  DATA) 

THEN  SET  ERROR  FLAG=0 
END!  F 

IF(1ST  59  SE  '  OR  NOT  60  SEC  OF  GOOD  DATA) 

THEN  SET  AVERAGE  MISSING 
ELSE  COMPUTE  AVERAGE  OF  60  GOOD  VALUES 
IF  WS  AVG  .LE.  2 

THEN  SET  WS  AVG  =  0  (calm  conditions) 

ELSE  CONTINUE 
ENOIF 

STORE  AVERAGE  IN  RAM 
CONVERT  TO  ASCII  DECIMAL 
STORE  ASCII  IN  BUFFER 
ENOIF 

ENOIF 

RESCHEDULE  FOR  NEXT  SECOND 

RETURN 

END 

ERROR  PROCESSING; 

WS  CHE  KS  FOR  VOLTAGE  LIMITS,  0  TO  1024. 

WS  .GT.  125  KNOTS  IS  ERROR 
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WSCNT-  ERROR  COUNT  INCREMENTED  WITH  EACH  FAILURE 

1  SEC  VALUE  SET  TO  OFFH,  AVG  SET  TO  OFFH,  ASCII  AVG='M' 
WSFLG-  HE  ERROR  FLAG  IS  RESET  TO  0  AFTER  5  SECONDS  OF  GOOD  DATA. 

GUST 


Purpose-  Gust  calculates  the  lO-minute  maximum  gust  and  1-minute 
wind.  It  is  called  once  each  minute. 


Var i a  1 e 
BI NASD 
SCHED 
PUSHDN 
AVG 
MXX 

WSIAVG 

WS  TBL 

GSTTBL 

GSTCUR 

GSTASC 

GSTMN 

PKWASC 


Names : 

-  CONVERTS  BINARY  TO  ASCII  DECIMAL 

-  SCHEDULES  ROUTINE  IN  SCAN  TABLE 

-  PUSHES  DOWN  STACK  WITH  1-BYTE  ENTRIES 

-  AVERAGES  TABLE  WITH  1-BYTE  ENTRIES 

-  FINDS  MAXIMUM  IN  BUFFER 

-  1-MIN  AVERAGE  WIND  SPEED 

-  MIN  STACK  FOR  WIND  SPEED 

-  GUST  10-MIN  STACK 

-  CURRENT  GUST 

-  GUST  ASCII  BUFFER 

-  ROUTINE  NAME  IN  SCAN  TABLE 

-  PEAK  WIND  ASCII  BUFFER 


Method : 


PUSH  DOWN  lO-MINUTE  STACK 

GET  1-MIN  AVERAGE  WIND  SPEED  FROM  RAM 

IF(WS  AVERAGE  MISSING) 

THEN  GUST  MISSING  (-1  IN  GSTCUR.  BLANKS  IN  GSTASC) 
PEAK  WIND  MISSING  (BLANKS  IN  PKWASC) 

ELSE  TAKE  ONE-MINUTE  WS  MAXIMUM 
STORE  MAX  IN  10-MIN  TABLE 
CONVERT  1-MIN  MAXIMUM  TO  ASCII  DECIMAL 
STORE  IN  PEAK  WIND  ASCII  BUFFER 
DETERMINE  MAXIO  IN  10-MIN  TABLE 
IF(MAX10.GE.14.AND.MAX10.GE.(1  MIN  AVG-hS)) 
THEN  SET  GUST  =  MAXIO 

CONVERT  TO  ASCII  DECIMAL 
STORE  IN  ASCII  BUFFER 
ELSE  GUST  MISSING 
ENDIF 

ENDIF 

RESCHEDU  E  FOR  NEXT  MINUTE 

RETURN 

END 


ERROR  PROCESSING- 

IF  GUST  IS  MISSING.  GSTCUR  IS  SET  TO  -1  AND 
GSTASC  IS  FILLED  WITH  BLANKS 


peak 
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3.2.4  WIND  DIRECnOU 

Wind  diri^ction  data  is  processed  by  subroutines  "WO"  and  "WNDDIR". 
WD 


Purpos  :  Sample  the  wind  direction  sensor's  inputs  (remote  A/D 
channels  5,  6,  and  7)  once  a  second,  convert  the  data  to  a  wind 
direction  reading  and  average  samples  over  1  minute  to  form  a  1  minute 
wind  direction. 

Varable  Names' 

ADTBL  -  RAM  ADDRESS  OF  THE  REMOTE  A/D  DATA  BUFFER 
WDSEC  -  MODULE  TIME  TABLE  ADDRESS  OF  'WO'  MODULE. 

WDIAVG-  RAM  ADDRESS  OF  1  MINUTE  WIND  DIRECTION  AVERAGE 
WDFAIL-  1  SECOND  FAILURE  COUNT 
WNDAVG-  RUNNING  AVERAGE  STORAGE 

ATAP,BTAP,  CTAP-TEMPORARY  STORAGE  FOR  WIND  DIRECTION  PHASES. 

Method : 


THREE  WIND  DIRECTION  PHASES  ARE  SAMPLED  EACH  SECOND.  EACH 

PHASE  IS  SCALED  BY  EXTRACTING  THE  8  MSB'S  FROM  THE  12  BIT 

SAMPLE,  I.E.  DIVIDING  BY  16.  WIND  DIRECTION  IS  THEN 

CALCULATED  BY  DETERMINING  THE  PROPER  PHASE  TO  BE  USED 

BASED  ON  THE  RELATIVE  MAGNITUDES  OF  THE  PHASES.  THE  RESULTANT  RUNNING 

WIND  DIRECTION  IS  SCALED  TO  255/360. 


GET- 

A=('CH.5)  '6  (TRUNCATED  TO  8  BITS) 
8=(CH.6)/16  (TRUNCATED  '•  "  "  ) 

C=(CH  .7)  16  (TRUNCATED  "  "  "  ) 

IF  A  .GT.  HIGH  LIMIT  (119  DEGREES) 

.  THEN  IF  A  .GT.  B  AND  A  .GT.  C 

THEN  IF  B+C  .LE.  A  AND  B+C 


.GT.  LOWER  LIMIT(59 

DEGS. SCALED, 


THEN  IF  B/2  .GT.  42 

THEN  DIRECTI0N=B/2-42 
ELSE  DIRECTI0N=B/2+300  SCALED  (212) 
ENDIF 
GO  TO  AVG 


.  ELSE  INCREMENT  FAILURE  COUNT 

.  GO  TO  FAIL 

ENDIF 

ENDIF 


ENDIF 

IF  B  .GT.  HIGH  LIMIT 
.  THEN  IF  B  .GT.  C  AND  B  .GT.  A 

THEN  IF  C+A  .LE.  B  AND  C+A  .GT.  LOWER  LIMIT 

.  THEN  DIRECTI0N=C/2+60  DEGREES  SCALED  (42) 
60  TO  AVG 
.  ELSE  GO  TO  FAIL 
ENDIF 

ENDIF 

ENDIF 


42) 
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C  .GT.  HIGH  LIMIT 
THEN  IF  C  .GT.  B  AND  C  .GT.  A 

.  THEN  IF  B+A  .LE.  C  AND  B+A  .GT.  42 

.  THEN  DIRECTI0N=A/2+180  DEGREES  SCALED  (128) 
GO  TO  AVG 
.  ELSE  GO  TO  FAIL 
ENDIF 


ENDIF 


ENDIF 

IF  A=B  AND 
.  THEN  IF 


ND  B  .GE.  EQUAL  LIMIT  (120 
IF  C  .LT.  LOWER  VALUE  (3) 

.  THEN  DIRECTION  =  C/2+60 
GO  TO  AVG 
.  ELSE  GO  TO  FAIL 
ENDIF 


SCALED) 

DEGREES  SCALED 


ENDIF 

IF  B=C  AND  B  .GE.  EQUAL  LIMIT 
.  THEN  IF  A  .LT.  LOWER  VALUE  (3) 

.  THEN  D  RECTION  =  A '2  +  180  DEGREES  SCALED  (128) 

GO  TO  AVG 
ELSE  GO  TO  FAIL 
ENDIF 

ENDIF 

IF  A=C  AND  A  .GE.  EQUAL  LIMIT 
.  THEN  IF  B  .LT.  LOWER  LIMIT  (3) 

.  THEN  IF  B/2  .GT.  42 

.  THEN  DIRECTI0N=B/2-42 

ELSE  DIRECTI0N=B/2+300  DEGREES  SCALED 
ENDIF 
GO  TO  AVG 
.  ELSE  GO  TO  FAIL 


(218) 


GO  TO  AVG 
.  ELSE  GO  TO  FAIL 
ENDIF 

ENDIF 

FAIL:  INCREMENT  FAILURE  COUNT 
RESCHEDULE  FOR  1  SECOND 
RETURN 

AVG:  COMPUTE  INSTANTANEOUS  AVERAGE  (I 
AVG= INSTANTANEOUS- PREVIOUS  AVERAGE 

(MODULO  255.  I.E.  SHIFT  RIGHT  5  BITS;  AVG= ( I -AVG )/32+AVG) 
(1  MINUTE  AVERAGE*  AVG/32) 

RESCHEDULE  FOR  1  SECOND 
RETURN 
END 

ERROR  PROCESSING: 

EACH  PHASE  IS  TESTED  AGAINST  DESIGNATED  LIMITS.  THE  SUM  OF 
THE  TWO  SMALLER  PHASES  MUST  BE  LESS  THAN  THE  LARGER  PHASE. 

FOR  EACH  FAILURE  DETECTED.  A  FAILURE  COUNT  IS  INCREMENTED, 

TO  BE  USED  BY  'WNDDIR'  TO  DETERMINE  IF  THE  1  MINUTE  AVERAGE 
ACCEPTABLE.  THE  FAILURE  COUNT  IS  RESET  EACH  MINUTE 
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MNDDIR 


Purpose:  Compute  wind  direction  once  per  minute,  true  and  magnetic, 

convert  both  to  lO's  of  degrees  in  ASCII  for  reporting. 

Variable  Names: 

WDFAIL-1  MIN.  FAILURE  COUNT  FOR  DIRECTION 
WDIAVG-WINO  DIRECTION  1-MINUTE  AVERA6E(5  BYTES) 

WS1AV6-WIND  SPEED  1-MINUTE  AVERAGE  (5  BYTES) 

MAGOFF-MAGNETIC  NORTH  DIRECTION  OFFSET 
BINASD-BINARY  TO  ASCII  DECIMAL  CONVERSION 
SCHED  -SCHEDULE  A  MODULE  FOR  EXECUTION  BY  'SCAN' 

MOUT  -OUTPUT  ■  M'  TO  AN  ASCII  BUFFER 

WDlASC-1  MINUTE  DIRECTION  IN  lO'S  OF  DEGREES  ASCII 
WDMN  -1  MINUTE  MAGNETIC  WIND  DIRECTION 

WOMASC-1  MINUTE  MAGNETIC  DIRECTION  IN  ID'S  OF  DEGREES  ASCII 
WDCNT  -WIND  DIRECTION  ERROR  COUNT 

Method : 

IF  WD1ASC=0.  I.E.  ASCII  BUFFER  EMPTY 
A:  THEN  SET  ASCII  BUFFERS='M' 

CLEAR  1  MINUTE  FAILURE  COUNT 
RESCHEDULE  FOR  1  MINUTE 
RETURN 

ELSE  IF  FAILURE  COUNT  .6E.  3 

.  THEN  INCREMENT  ERROR  COUNT  (WDCNT) 

GO  TO  A. 

ENDIF 

ENDIF 

IF  SPEED  AVERAGE=0 

THEN  PUT  0  IN  TRUE  ASCII  WIND  DIRECTION  BUFFER  (WDlASC) 

ELSE  CALL  CONVERT  (CONVERT  DIRECTION  TO  lO'S  OF  DEGREES) 

CONVERT  TO  ASCII  (BINASD) 

STORE  IN  TRUE  ASCII  BUFFER  (WDlASC) 

ENDIF 

IF  TRUE  DIRECTION=0 

THEN  PUT  0  IN  MAGNETIC  ASCII  BUFFER 
ELSE  MAGNETIC  DIR=TRUE  AVG.+MAG.  OFFSET) 

CALL  CONVERT(CONVERT  TO  lO's  OF  DEGREES) 

CONVERT  TO  ASCII 

STORE  IN  MAGNETIC  ASCII  BUFFER  (WDMASC) 

ENDIF 

CLEAR  1  MINUTE  FAILURE  COUNT 
RESCHEDULE  FOR  1  MINUTE 
RETURN 
CONVERT: 

IF  DIRECTION  .LE.  7  DEGREES  (SCALED) 

THEN  SET  DIRECTION=36  (360  degrees) 

ELSE  CONVERT  DIRECTION  FROM  255  TO  360  SCALING 
DIRECTION  IN  lO'S  OF  DEGREES*  DIRECTION/7 
ENDIF 
RETURN 
END 

ERROR  PROCESSING: 

FOR  EACH  1  MINUTE  FAILURE  COUNT  .6E.  3  THE  WIND  DIRECTION 
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ERROR  COUNT  IS  INCREMENTED  AND  WIND  DIRECTION  OUTPUT  IS  MISSING  'M'. 


ASSUMPTIONS:  CURRENT  WIND  SPEED  HAS  BEEN  CALCULATED  PRIOR  TO  THE 
EXECUTION  OF  THIS  MODULE. 

3.12.5  PRECIPITATION 

Precipitation  data  is  processed  by  subroutine  "PRECIP". 

PRECIP 

Purpose;  Identification  and  tracking  of  precipitation,  outputs  a 
remark  indicating  the  beginning  and  ending  times  of  precipitation, 
It  is  executed  once  a  minute. 


Variable 
TIMASC 
SCHEO 
STANUM 
PRECMN 
RASC 
TIMASC 
MI  NS 
ZRASC 
EVENT 


used  in  this  version) 


Names : 

CURRENT  TIME  (ASCII)  IN  RAM 

SCHEDULE  A  ROUTINE  FOR  EXECUTION  BY  'SCAN' 

STORE  A  CONSTANT  X  TIMES  IN  RAM 

MODULE  ENTRY  POINT  IN  'SCAN'  TIME  TABLE 

PRECIPITATION  REMARK  ASCII  BUFFER  ADDRESS 

CURRENT  TIME  ASCII  BUFFER  ADDRESS 

CURRENT  MINUTE 

FREEZING  RAIN  REMARK  ASCII  BUFFER  ADDRESS 
EVENT  SENSOR  WORD  IN  RAM 

Bit  7  nOT'WD - 

6  -  FREEZING  RAIN  (not  used  in  this  ve 
5  -  THUNDERSTORM 
4  -  RAIN 
3  -  NOT  USED 
2  -  ** 

1  -  **  ** 

0  -  OAY/NIGHT 


PCPFLG-  PRECIPITATION  FLAG  WORD 

BIT  7  -  MARKS  CHANGING  OF  HOUR 

6  -  RAIN  IN  PROGRESS  INDICATOR 
5  -  NOT  USED  (SET  TO  1) 

4  -  RAIN.  FIRST  INDICATOR 
3-15  MINUTE  COUNTER 


TIMSTR-  STORAGE  FOR  ASCII  BEGINNING  AND  ENDING  TIMES 
Method : 

IF  FIRST  EXECUTION 

THEN  CLEAR  ASCII  RAIN  AND  FREEZING  RAIN  BUFFERS 
ENDIF 

GET  CURRENT  EVENT  SENSOR  DATA 
IF  EVENT  SENSOR  WORD  BIT  4  (RAIN)  =  0 
THEN  CLEAR  BIT  4  OF  PRECIP  FLAG  WORD 
ELSE  RESET  BIT  4  OF  EVENT  SENSOR  WORD 
SET  BIT  4  OF  PRECIP  FLAG  WORD 

ENDIF 
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IF  PRECIP  FLAG  WORD  .GE.  80H  AND  .LE.BOH  (Chg  in  Hr.  &  rain  not 

reported  in  previous  15  minutes  ?) 

THEN  CLEAR  ASCII  BUFFER 

ELSE  IF  PRECIP  FLAG  WORD  .GE.  EOH  (Chg  in  Hr  &  rain  prev.  reported?) 
THEN  CLEAR  BXXEXX  IN  ASCII  BUFFER 
ENDIF 

ENDIF 

CLEAR  HOUR  BIT  (BIT  7)  IN  FLAG  WORD 

IF  PRECIP  FLAG=10H  (Rain  1st  Ind.  and  mins,  count  =  0?) 

THEN  SET  BITS  6,5.4  OF  FLAG  WORD(Set  rain  in  prog. -bit  5,&  1st  Ind.) 

SET  PBXX  IN  ASCII  BUFFER,  RAIN  BEGINNING 
ELSE  CONTINUE 
ENDIF 

IF  PRECIP  FLAG  WORD  .GE.  60H  AND  .LE.  6FH(rain  in  prog.&  min.=0  to  15?) 

THEN  INCREMENT  PRECIP  FLAG  WORD  (15  MINUTE  COUNTER) 

.  IF  PRECIP  FLAG  WORD  =  61H  (Rain  prev.  Ind.  but  not  at  present 

and  minute  count  =  1?) 

.  THEN  SAVt  CURRENT  TIME  AS  END  TIME  TO  BE  OUTPUT  IN  14  MINS. 
ENDIF 

ELSE  CONTINUE 
ENDIF 

IF  PRECIP  FLAG=6FH  (Rain  prev.  Ind.  but  not  at  present  &  count  =  15?) 
THEN  CLEAR  PRECIP  FLAG 

OUTPUT  PEXX  END  TIME  (RAIN  ENDED  14  MINS.  AGO) 

ELSE  CONTINUE 
ENDIF 

IF  PRECIP  FLAG  .GE.  70H  (Rain  prev.  Ind.  &  rain  1st  Ind.  set?) 

THEN  SET  PRECIP  FLAG=60H  (Rain  Still  in  progress .reset  15  min  count) 
ENOIF 

SAVE  CURRENT  TIME 
IF  CURRENT  MINUTE»00 

THEN  SET  PRECIP  FLAG  BIT  7=1  (Set  hour  change  indicator  bit) 

ENDIF 

SAVE  PRECIP  FLAG  WORD 
RESCHEDULE  FOR  1  MINUTE 
RETURN 
END 

NO  ERROR  PROCESSING 
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3.12.6  THUNDERSTORM 


Thunderstorm  data  is  processed  by  subroutines  "TUNDER"  and  "LITEN". 
TUNDER 

Purpose:  To  read  and  reset  the  events  port  and  store  the  results  in 
RAM.  To  check  for  lightning  in  the  past  second  and  set  a  flag  if 
present . 

Var  able  Names: 

SCHED  -  MODULE  SCHEDULER  FOR  EXECUTION  BY  'SCAN* 

TUN  -  ENTRY  IN  'SCAN'  TIME  TABLE  FOR  'TUNDER' 

TUNFLG  -  THUNDERSTORM  FLAG  WORD  IN  RAM  (accessed  also  by  subroutine 

'LITEN  '  ) 

BIT  7  -  Marks  beginning  of  new  hour  (BOH) 

BIT  6  -  Storm  reported  in  progress  (40H) 

BIT  5  -  2nd  stroke,  storm  beginning  (20H) 

BIT  4  -  Lightning  strike,  set  by  subroutine  TUNDER  (lOH) 
BIT  3  -  MSB  of  15  minute  counter 
BIT  2  -  "  " 

BIT  1  -  .... 

BIT  0  -  LSB  of  " 

EVENT  -  EVENT  SENSOR  WORD  IN  RAM 

rrrr  -  not  used 

6  -  FREEZING  RAIN  (not  used  in  this  version) 

5  -  THUNDERSTORM 
4  -  RAIN 
3  -  NOT  USED 
2  -  **  ** 

1  -  "  '* 

0  -  DAY/NIGHT 

Method : 

READ  EVENT  SENSOR  PORT  (8-BITS) 

COMPLEMENT  EVENT  DATA  (Invert  all  8  data  bits) 

LOGICALLY  OR  DATA  WITH  PREVIOUS  EVENT  DATA  WORD 
STORE  IN  'EVENT'  DATA  WORD  IN  RAM 
RESET  EVENT  ELECTRONICS 

IF  EVENT  DATA  WORD  BIT  5=1  (Strike  detected  this  second) 

.  THEN  IF  TUNFLG  FLAG  WORD  BIT  4  .NE  .  1 

.  THEN  SET  TUNFLG  BIT  4=1  (FIRST  HIT  THIS  MINUTE) 

ELSE  SET  TUNFLG  BIT  5=1  (2ND  HIT  THIS  MINUTE) 

ENDIF 

ELSE  CONTINUE 
ENDIF 

RESCHEDULE  FOR  NEXT  SECOND 

RETURN 

END 


LITEN 


Purpose:  To  determine  the  beginning  and  ending  times  of  thunderstorms 

according  to  the  prescribed  algorithm.  Output  a  “T"  for  thunderstorm, 
"BXX"  for  beginning  time  and  “EXX*'  for  ending  time.  The  program  is 
executed  once  each  minute. 


Var  able  Names : 

BINASD  -  BINARY  TO  ASCII 

SCHED  -  SCHEDULE  MODULE  FOR  EXECUTION  BY  SCAN 

TRMASC  -  THUNDERSTORM  REMARK  ASCII  BUFFER 

TIMASC  -  CURRENT  TIME  (ASCII)  BUFFER  ADDRESS  IN  RAM  (HHMM) 

TIMSTR  -  BEGINNING  AND  ENDING  TIME  STORAGE 
LIT  -  MODULE  ENTRY  POINT  IN  'SCAN'  TIME  TABLE  FOR  LITEN 
TUNFLG  -  THUNDERSTORM  FLAG  WORD  IN  RAM  (changed  also  by  subroutine 
■TUNOER  '  ) 

BIT  7  -  Marks  beginning  of  new  hour  (BOH) 

BIT  6  -  Storm  reported  in  progress  (40H) 

BIT  5  -  2nd  stroke,  storm  beginning  (20H) 

BIT  4  -  Lightning  strike,  set  by  subroutine  TUNDER  (lOH) 
BIT  3  -  MSB  of  15  minute  counter 
BIT  2  -  " 

BIT  1  -  .... 

BIT  0  -  LSB  of  •' 

Method : 


GET  TUNFLG  FROM  RAM 
IF  TUNFLG  =  0 
THEN  RETURN 
ENDIF 

IF  TUNFLG  .GE.  BOH  AND  .LE.  BOH  (Hr.  chg  &  no  T'storm  reported  in 

prev.15  mins.?) 

THEN  CLEAR  TRMASC  (Clear  all  T'storm  remarks) 

ELSE  IF  TUNFLG  ,GE.  EOH  (Hr.  chg  &  T'storm  prev . reported?  ) 

THEN  CLEAR  BXXEXX  AND  SET  "T"  ONLY  IN  TRMASC 
ENDIF 


ENDIF 

IF  TUNGLG  .GE.  BOH 

THEN  SET  TUNFLG  =  TUNFLG 
ENDIF 

IF  TUNFLG  =  lOH 

THEN  SET  TUNFLG  =  20H 
GO  TO  "DONE" 

ELSE  CONTINUE 
ENDIF 

IF  TUNFLG  .GE.  20H  and  .LE. 
THEN  INCREMENT  TUNFLG 
IF  TUNFLG  =  2FH 

THEN  SET  TUNFLG  = 
ENDIF 

GO  TO  "DONE" 

ELSE  CONTINUE 
ENDIF 


-  BOH  (Clr.  Hr.  chg  bit) 

(1st  strike  ind.  this  min.?) 

(Set  bit  5,  possible  storm  begin  time) 


2EH  (.LT.  15  mins,  since  1st  strike?) 
(Yes,  incr.  15  min.  counter) 

(15  mins,  since  1st  &  only  strike?) 

0  (Yes,  clr.  flag  and  don't  report  T'storm) 
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IF  TUNFLG  .6E.  30H  AND  .LE.  3EH  (Two  strikes  within  14  minutes?) 
THEN  SET  TUNFLG  =  60H,  MOVE  TBXX  TO  TRMASC  (Yes, report  begin  time) 
GO  TO  "DONE" 

ELSE  CONTINUE 
ENDIF 

IF  TUNFLG  .GE.  60H  AND  .LE.  6EH  (.LT.  15  min. since  T'storm  reported?) 
.  THEN  INCREMENT  TUNFLG  (Yes,  incr.  15  min.  counter) 

IF  TUNFLG  .EQ.  61H  (1st  min. since  T'storm  reported  &  last  strike?) 

.  THEN  SAVE  TIME  AS  POSSIBLE  ENDTIME 

ENDIF 

.  IF  TUNFLG  =  6FH  (T'storm  reported  &  15  min.  since  last  strike?) 

.  THEN  SET  TUNFLG  =  0  (Yes,  clr  flag) 

MOVE  EXX  TO  TRMASC  (Set  T'storm  end  time) 

GO  TO  "DONE" 

.  ELSE  GO  TO  "OONEl" 

ENDIF 

.  ELSE  CONTINUE 
ENDIF 

IF  TUNFLG  .GE.  70H  (Strike  in  .LT.  15  min.  since  T'storm  reported?) 

THEN  SET  TUNFLG  =  60H  (Yes,  reset  15  min.  counter  for  end  time) 
ENDIF 
DONE: 

GET  MINUTES  FROM  RAM 

SAVE  MINUTES  (Save  current  time  in  TIMSTR) 

DONEl  : 

IF  MINUTES  =  0  (Hr.  chg.?  ) 

THEN  TUNFLG  =  TUNFLG  +  BOH  (Yes,  set  bit  7) 

ENDIF 

SAVE  TUNFLG 

RESCHEDULE  FOR  NEXT  MINUTE 

RETURN 

END 

NO  ERROR  PROCESSING 
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3.12.7  PRESSURE  &  ALTIMETER  SETTING 

Pressure  and  altimeter  setting  data  are  processed  by  subroutines 
"CALINT",  "PRSAQl",  PRSAQ2'',  and  “PRSPCl". 

CALINT 

PURPOSE:  THIS  MODULE  SAMPLES  A  REFERENCE  VOLTAGE  THAT 

PROVIDES  3.33  VOLTS  TO  ONE  CHANNEL  OF  THE  INTERNAL 
A/D  CONVERTER.  IF  IT  DETECTS  AN  OUT  OF  RANiSI 
VOLTAGE  IT  SETS  AN  ERROR  FLAG  AND  DISPLAYS 
AN  ERROR  MESSAGE  ON  THE  CONSOLE.  THE  ERROR  FLAG 
IS  USED  BY  THE  PRESSURE  ACQUISITION  MODULES  TO 
VALIDATE  THE  PRESSURE  READINGS. 

EXECUTION:  SCHEDULED  TO  EXECUTE  JUST  PRIOR  TO  THE  PRESSURE 

ACQUISITION  MODULES  EACH  10  SEC. 

IT  IS  CALLED  BY  SCAN  AND  RESCHEDULES  ITSELF  FOR 
THE  NEXT  10  SEC  TIME. 

DESCRIPTION:  THIS  MODULE  CHECKS  A  REFERENCE  VOLTAGE 

DERIVED  FROM  THE  COMPUTER'S  5  VOLT  POWER  SUPPLY 
TO  VERIFY  THAT  THE  COMPUTER  VOLTAGE  AS  WELL  AS  THE 
INTERNAL  A/O  CONVERSION  CARD  ARE  OPERATING  CORRECTLY 
AND  ARE  WITHIN  TOLERANCE. 

IF  IT  IS  NOT,  THEN  AN  ERROR  FLAG(CALFLG)  IS  SET,  AND 
AN  ERROR  MESSAGE  IS  OUTPUT  TO  THE  CONSOLE. 

IT  TAKES  30  CONSECUTIVE  GOOD  READINGS  TO  CLEAR  THE 
ERROR  FLAG(5  MINUTES). 

Variable  Names: 

CALLMT  -  THE  LIMIT  THAT  THE  VOLTAGE  MAY  VARY  FROM 
NORMAL.  IT  IS  PRESENTLY  SET  TO  8  (9.77 
MILLIVOLTS)  . 

CALVOL  -  THE  VALUE  EXPECTED  FROM  THE  SAMPLED  VOLTAGE. 

PRESENTLY  SET  TO  3.332  VOLTS. 

CALOG  -  THE  CHANNEL  AND  GAIN  THE  SAMPLED  REFERENCE  IS 
WIRED  TO  THE  INT.  A/D.  PRESENTLY  CHANNEL  13. 
CALFLG  -  FLAG  INDICATES  WHEN  -1  THAT  PRESSURE  VOLTAGE 
SUPPLY  BAD 

CALERR  -  COUNTER  THAT  REQUIRES  30  GOOD  PRESSURE  VOLTAGE 
SUPPLY  READINGS  BEFORE  THE  ERROR  FLAG  IS 
CLEARED. 

INITIALIZATION 

REQUIREMENTS:  ERROR  COUNTER  (CALERR)  AND  ERROR  FLAG  (CALFLG)  SET  TO 

ZERO 

INPUTS:  NONE 

OUTPUTS:  ERROR  FLAG  SET  AND  MESSAGE  TO  CONSOLE  DISPLAY  IF  BAD 

VOLTAGE  . 
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METHOD: 


GET  CALIBRATION  VOLTAGE 
IF(VOLTAGE  EXCEEDS  LIMITS) 

.  THEN  SET  ERROR  COUNT  TO  30  (CALERR) 

OUTPUT  ERROR  MESSAGE  TO  DISPLAY 
SET  ERROR  FLAG  =  -1  (CALFLG) 

.  ELSE  IF  ERROR  COUNTER  NOT  ZERO 

.  THEN  DECREMENT  ERROR  COUNTER 
IF  ERROR  COUNTER  EQUAL  ZERO 
.  THEN  RESET  ERROR  FLAG  =  0  (CALFLG) 

ENOIF 

ENDIF 

ENDIF 

RESCHEDULE  IN  TEN  SECONDS 

RETURN  TO  SCAN 

END 

ASSUMPTIONS;  1.  MUST  HAVE  REFERENCE  VOLTAGE  WIRED  TO  INTERNAL  A/D 

CH  13 

2.  MUST  HAVE  SENSOR  INTERFACE  BOARD  INSTALLED 

PRSAQl 

PURPOSE; 

PRSAQl  ACQUIRES  PRESSURE  DATA  FROM  THE  FIRST  SENSOR  THROUGH  THE  LOCAL 
A/D  CONVERTER  AND  ALSO  READS  THE  OFFSET  VOLTAGE  FOR  THE  FIRST  SENSOR 
ON  A  SEPARATE  CHANNEL.  THE  MODULE  THEN  ADDS  THE  OFFSET  TO  THE 
PRESSURE  AND  SAVES  THE  RESULT  IN  A  ONE  MINUTE  (6  PER  MINUTE)  STACK. 

DESCRIPTION: 

THE  MODULE  IS  SCHEDULED  TO  EXECUTE  ONCE  EACH  10  SECONDS.  PRESSURE 
DATA  FROM  SENSOR  #1  IS  READ  FROM  THE  INTERNAL  A/D  CONVERTER  AND  SAVED 
IN  A  TEMPORARY  LOCATION.  AN  OFFSET  VOLTAGE  IS  READ  FROM  ANOTHER 
CHANNEL  OF  THE  A/O  CONVERTER  AND  ADDED  TO  THE  PRESSURE  DATA.  THIS 
OFFSET  VOLTAGE  IS  ADJUSTABLE  AND  IS  USED  TO  CALIBRATE  THE  SENSOR 
READING.  THE  PRESSURE  DATA  WITH  OFFSET  ADDED  IS  THEN  SAVED  IN  A  DATA 
STACK  CONTAINING  THE  LAST  SIX  READINGS.  THE  DATA  IS  THEN  COMPARED 
AGAINST  A  HIGH  AND  LOW  LIMIT  TO  BE  SURE  IT  IS  VALID.  IF  IT  EXCEEDS 

THE  LIMITS  THE  DATA  IS  REPLACED  BY  A  -1  (OFFH)  IN  THE  STACK.  FINALLY 

THE  DATA  IS  COMPARED  TO  THE  LAST  READING  TO  SEE  THAT  THE  DIFFERENCE 
DOESN'T  EXCEED  A  SET  AMOUNT  (PRESENTLY  PRSDEV  =  20  =  0.072  INCHES 
HG.).  IF  IT  DOES  EXCEED  THIS  VALUE  THEN  THE  DATA  IS  REPLACED  BY  -1. 
THE  MODULE  THEN  RESCHEDULES  FOR  THE  NEXT  10  SECOND  PERIOD  AND  RETURNS 
TO  SCAN. 

Variable  Names : 

PRSIDA  -  SENSOR  #1  RAW  PRESSURE  DATA  VALUE 
PRSlOF  -  PRESSURE  SENSOR  #1  DATA  STACK  (6  WORDS) 

PRIERF  -  ERROR  FLAG  INITIALLY  SET  TO  0 

PRIERC  -  PRESSURE  SENSOR  ERROR  COUNTER  INITIALLY  SET  TO  0 
PRSICH  -  EQUALS  03  (A/D  channel  #),  PRESSURE  SENSOR  #1 

PIOFCH  -  EQUALS  15  (A/D  channel  #),  SENSOR  #1  OFFSET 

HILMT  -  EQUALS  3768,  HIGH  LIMIT  SENSOR  VOLTAGE  (4.600  V.  MAX.) 

LOLMT  -  EQUALS  0  ,  LOW  LIMIT  SENSOR  VOLTAGE  (0.000  V.) 

PRSDEV  -  EQUALS  20,  ALLOWED  PRESSURE  DEVIATION 
BETWEEN  10  SECOND  READINGS. 
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Method : 

MOVE  1  MINUTE  STACK  DOWN 
GET  PRESSURE  AND  OFFSET  AND  ADD 
SAVE  BOTH  DATA  AND  OFFSET  DATA  VALUES 
IF  DATA  EXCEEDS  HIGH  LIMIT 

THEN  SAVE  -1  IN  DATA  LOCATION 

SET  ERROR  FLAG  AND  INCREMENT  ERROR  COUNT 
ELSE  CONTINUE 
ENDIF 

IF  DATA  IS  BELOW  LOWER  LIMIT 
THEN  SAVE  -1  IN  DATA  STACK 

SET  ERROR  FLAG  AND  INCREMENT  ERROR  C<:^IINT 
ELSE  CONTINUE 
ENDIF 

IF  DIFFERENCE  BETWEEN  LAST  TWO  READINGS  EXCEEDS  PRSDEV 
THEN  SAVE  -1  IN  DATA  STACK 

SET  ERROR  FLAG  AND  INCREMENT  ERROR  COUNT 
ELSE  SAVE  DATA 
ENDIF 

RESCHEDULE  IN  10  SECONDS 

RETURN  TO  SCAN 

END 


PRSAQ2 

PURPOSE: 

PRSAQ2  ACQUIRES  PRESSURE  DATA  FROM  THE  SECOND  SENSOR  THROUGH  THE  LOCAL 
A/D  CONVERTER  AND  ALSO  READS  THE  OFFSET  VOLTAGE  FOR  THE  SECOND  SENSOR 
ON  A  SEPARATE  CHANNEL.  THE  MODULE  THEN  ADDS  THE  OFFSET  TO  THE 
PRESSURE  AND  SAVES  THE  RESULT  IN  A  ONE  MINUTE  (6  PER  MINUTE  )  STACK. 

DESCRIPTION: 

THE  MODULE  IS  SCHEDULED  TO  EXECUTE  ONCE  EACH  10  SECONDS.  PRESSURE 
DATA  FROM  SENSOR  #2  IS  READ  FROM  THE  INTERNAL  A/D  CONVERTER  AND  SAVED 
IN  A  TEMPORARY  LOCATION.  AN  OFFSET  VOLTAGE  (SEPARATE  FROM  SENSOR  #l‘s 
OFFSET  ADJUSTMENT)  IS  READ  FROM  ANOTHER  CHANNEL  OF  THE  A/D  CONVERTER 
AND  ADDED  TO  THE  PRESSURE  DATA.  THIS  OFFSET  VOLTAGE  IS  ADJUSTABLE  AND 
IS  USED  TO  CALIBRATE  THE  SENSOR  READING.  THE  PRESSURE  DATA  WITH 
OFFSET  ADDED  IS  THEN  SAVED  IN  A  DATA  STACK  CONTAINING  THE  LAST  SIX 
READINGS.  THE  DATA  IS  THEN  COMPARED  AGAINST  A  HIGH  AND  LOW  LIMIT  TO 
BE  SURE  IT  IS  VALID.  IF  IT  EXCEEDS  THE  LIMITS,  THE  DATA  IS  REPLACED 
BY  A  -1  (OFFH)  IN  THE  STACK.  FINALLY  THE  DATA  IS  COMPARED  TO  THE  LAST 
READING  TO  SEE  THAT  THE  DIFFERENCE  DOESN'T  EXCEED  A  SET  AMOUNT 
(PRESENTLY  PRSDEV  =  20  =  0.072  INCHES  HG.).  IF  IT  DOES  EXCEED  THIS 
VALUE  THEN  THE  DATA  IS  REPLACED  BY  -1.  THE  MODULE  THEN  RESCHEDULES 
FOR  THE  next  10  SECOND  PERIOD  AND  RETURNS  TO  SCAN. 

Variable  Names: 

PRS2DA  -  SENSOR  #2  RAW  PRESSURE  DATA  VALUE 
PRS20F  -  PRESSURE  SENSOR  #2  DATA  STACK  (6  WORDS) 

PR2ERF  -  ERROR  FLAG  INITIALLY  SET  TO  0 

PR2ERC  -  PRESSURE  SENSOR  ERROR  COUNTER  INITIALLY  SET  TO  0 

PRS2CH  -  EQUALS  04  (A/D  channel  #)  ,  PRESSURE  SENSOR  #2 

P20FCH  -  EQUALS  14  (A/D  channel  #)  ,  SENSOR  #2  OFFSET 

HILMT  -  EQUALS  3768  ,  HIGH  LIMIT  SENSOR  VOLTAGE  (3768=4.600  V.MAX.) 

LOLMT  -  EQUALS  0  ,  LOW  LIMIT  SENSOR  VOLTAGE 
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PRSDEV  -  EQUALS  20,  ALLOWED  PRESSURE  DEVIATION 
BETWEEN  10  SECOND  READINGS. 


Method : 

MOVE  1  MINUTE  STACK  DOWN 
GET  PRESSURE  AND  OFFSET  AND  ADD 
SAVE  BOTH  DATA  AND  OFFSET  DATA  VALUES 
IF  DATA  EXCEEDS  HIGH  LIMIT 

THEN  SAVE  -1  IN  DATA  LOCATION 

SET  ERROR  FLAG  AND  INCREMENT  ERROR  COUNT 
ELSE  CONTINUE 
ENOIF 

IF  DATA  IS  BELOW  LOWER  LIMIT 
THEN  SAVE  -1  IN  DATA  STACK 

SET  ERROR  FLAG  AND  INCREMENT  ERROR  COUNT 
ELSE  CONTINUE 
ENDIF 

IF  DIFFERENCE  BETWEEN  LAST  TWO  READINGS  EXCEEDS  PRSDEV 


THEN  SAVE  -1  IN  DATA  STACK 

SET  ERROR  FLAG  AND  INCREMENT  ERROR  COUNT 
ELSE  SAVE  DATA 
ENDIF 

RESCHEDULE  IN  10  SECONDS 


RETURN  TO  SCAN 
END 


PRSPCl 


PURPOSE:  THIS  MODULE  TAKES  RAW  DATA  FROM  EACH  OF  TWO  PRESSURE  DATA 

STACKS,  AVERAGES,  AND  CALCULATES  STATION  PRESSURE  FOR  EACH.  IT  ALSO 
DETERMINES  THE  ALTIMETER  SETTING  FROM  THE  LOWER  OF  THE  TWO  PRESSURES. 
THE  MODULE  IS  EXECUTED  ONCE  EACH  MINUTE. 

DESCRIPTION: 

THE  MODULE  GETS  THE  SIX  10  SEC  READINGS  FROM  THE 
ONE  MINUTE  OATA  STACK,  AVERAGES  IT  AND  CALCULATES 
STATION  PRESSURE  USING  THE  FORMULA- 

S.P.=RAW  DATA  X  0.0036  +  17.718  (.0036  IS  FACTOR  TO  CONVERT  RAW  DATA 
TO  INCHES  HG.  &  17.718  IS  THE  SENSOR  OFFSET).  IF  ANY  OF  THE  SIX 
READINGS  ARE  -1  THEN  THE  ERROR  FLAG  FOR  THAT  SENSOR 

IS  SET  TO  -1  AND  NO  PRESSURE  CALCULATION  IS  PERFORMED.  OTHERWISE  THE 
ERROR  FLAG  IS  CLEARED. 

THE  RESULT  IS  SAVED  AND  ALSO  CONVERTED  TO  ASCII  FOR 
DISPLAY.  THE  SAME  ROUTINE  IS  USED  TO  DERIVE  THE  PRESSURE 
FOR  SENSOR  #2.  NEXT,  THE  PRESSURES  ARE  COMPARED  TO  -1. 

IF  BOTH  ARE  -1  THEN  NO  PRESSURE  IS  AVAILABLE  AND 
AN  'M'  IS  OUTPUT.  IF  ONE  IS  -1,  THEN  THE  OTHER  PRESSURE 
IS  USED  TO  CALCULATE  ALTIMETER  SETTING  AND  A  PREFIX 
'E'  IS  PROVIDED.  IF  BOTH  ARE  OK,  THE  LOWER  OF  THE  TWO 
IS  USED  TO  FIND  ALTIMETER  SETTING. 

ALTIMETER  SETTING  IS  CALCULATED  USING  THE  FORMULA-- 
A.S.  =  (S.P.  -  PICONT)  X  A2C0NT  +  STATPR 
WHERE  A.S.  =  ALTIMETER  SETTING 

PICONT  =  PI  VALUE  FROM  STATION  HEIGHT  ABOVE  SEA  LEVEL 
TABLE. (PI  DULLES  CONSTANT  =  29573  ) 

A2C0NT  =  A2  VALUE  FROM  STATION  HEIGHT  ABOVE  SEA  LEVEL 
TABLE. (A2  DULLES  CONSTANT, 1/2  VALUE,  =  4953) 
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STATPR  =  STANDARD  PRESSURE  AT  SEA  LEVEL  (29 . 92 1  + .005 ) 
.005  IS  ADOEO  FOR  ROUNDING 

FINALLY  THE  TWO  STATION  PRESSURE  VALUES  DERIVED  ABOVE 
ARE  CHECKED  FOR  A  DIFFERENCE  GREATER  THAN  .04  INCH  HG. 

IF  GREATER,  THEN  THE  ALTIMETER  SETTING  IS  REPLACED  WITH 
AN  'M'. 

Variable  Names: 

PRSSGN  -  TEMPORARY  LOCATION  TO  SAVE  THE  SIGN  OF  THE 
SUBTRACTION  IN  THE  ALTIMETER  EQUATION. 

PRSERR  -  SET  TO  -1  IF  ALTIMETER  IS  'M* 

SET  TO  1  IF  ABS(#1-#2)  .GT.  0.04 
SET  TO  0  IF  PRESSURE  OK 

PRIERF  -  USED  TO  VERIFY  RAW  DATA  FROM  SENSOR  #1  OK 
PR2ERF  -  USED  TO  VERIFY  RAW  DATA  FROM  SENSOR  #2  OK 

INPUTS:  RAW  PRESSURE  DATA  FROM  2  SENSORS 

OUTPUTS:  1.  STATION  PRESSURE  IN  INCHES  HG  FOR  BOTH  SENSORS 

2.  ALTIMETER  SETTING  IN  ASCII 

3.  ASCII  STATION  PRESSURE  FOR  BOTH  SENSORS 

METHOD: 

GET  1  MINUTE  AVERAGE  FOR  PRESSURE  #1 
IF  EACH  PRESSURE  VALUE  OK  (NOT  -1) 

THEN  CONTINUE 
ELSE  SET  PRIERF  =  -1 

ENDIF 

CALCULATE  STATION  PRESSURE  #1 
CONVERT  TO  ASCII 

GET  1  MINUTE  AVERAGE  FOR  PRESSURE  #2 
IF  EACH  PRESSURE  VALUE  OK  (NOT  -1) 

THEN  CONTINUE 
ELSE  SET  PR2ERF=  -1 

ENDIF 

CALCULATE  STATION  PRESSURE  #2 
CONVERT  TO  ASCII 

FIND  GOOD  PRESSURE  FOR  ALTIMETER  CALCULATION 
IF  BOTH  BAD 

THEN  OUTPUT  'M' 

ENDIF 

IF  ONLY  ONE  PRESSURE  OK 

THEN  USE  IT  FOR  ALTIMETER  CALCULATIONS 
INSERT  PREFIX  "E"  FOR  ESTIMATED 
ELSE  CONTINUE 
ENDIF 

IF  BOTH  PRESSURES  GOOD 

THEN  DETERMINE  LOWER  VALUE  AND  USE  IT  FOR  ALTIMETER  CALC. 
ENDIF 

CALCULATE  ALTIMETER  SETTING 
CONVERT  TO  ASCII 

CHECK  IF  THE  ABSOLUTE  VALUE  OF  THE  RESULT  OF  SUBTRACTING 
THE  RAW  PRESSURES  IS  GREATER  THAN  0.04  INCHES  HG . 
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IF  GREATER  THAN  0.04 

THEN  OUTPUT  'M'  (Missing) 
ELSE  CONTINUE 

ENDIF 

RESCHEDULE  MODULE  FOR  NEXT  MINUTE 
RETURN  (TO  SCAN) 
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4.  FIELD  EVALUATION  AT  DULLES  AIRPORT 

The  ALWOS  system  was  installed  at  the  Dulles  International  Airport  for 
evaluation.  Output  from  ALWOS  was  collected  and  compared  with 
official  weather  observations  taken  by  personnel  from  the  collocated 
National  Weather  Service  (NWS)  Office  (WSO).  Data  collection  and 
analysis  were  performed  by  members  o-^  the  NWS  Test  and  Evaluation 
Division  (T&ED),  whose  offices  are  located  adjacent  to  Dulles 
Airport.  Maintenance  of  the  system  and  sensors  was  provided  by  the 
NWS  Integrated  Systems  L aboratory ( I SL ) .  The  field  evaluation  lasted 
for  roughly  six  months,  12  March  through  15  September  1981,  though 
data  continues  to  be  collected  and  the  system  monitored.  The  ALWOS 
was  not  used  operationally  during  the  field  evaluation.  Appendix  C 
contains  the  evaluation  plan. 

4  . 1  System  Configuration 

Figure  2-1  showed  the  ALWOS  system  in  block  diagram  form  as  configured 
for  the  Dulles  operation.  The  various  components  of  the  system  have 
been  discussed  in  detail  in  earlier  sections  of  this  report.  However, 
a  brief  overview  of  the  system  concept  and  operation  as  related  to  the 
field  evaluation  is  important. 

4.1.1  Sensors 

Most  of  the  sensors  are  centrally  located  on  the  airport,  close  to  the 
airport's  Rotating  Beam  Ceilometer  (RBC)  (cloud  measurement  system) 
and  a  transmi ssometer  (visibility  measurement  system).  The  sensors 
included  those  for  wind  speed/direction,  temperature/dew  point, 
thunderstorm,  visibility,  and  clouds.  All  sensors  were  installed 
according  to  established  procedures  for  each  instrument.  Except  for 
the  wind  sensor  which  is  located  at  20  feet  above  ground  level,  the 
remaining  sensors  are  at  heights  of  10  feet  or  lower. 

The  pressure  transducers,  precipitation,  and  day/night  sensors  are 
located  at  the  NWS  office,  about  .8  mile  from  the  main  group  of  ALWOS 
sensors.  The  precipitation  Yes/No  sensor  was  eventually  moved  to 
center  field  due  to  the  presence  of  a  nearby  large  air  conditioning 
unit  which  adversely  affected  sensor  output  (further  discussion  of 
this  problem  is  included  in  a  later  section  of  the  report).  At  Dulles 
Airport  the  NWS  observation  point  and  sensor  installations  are 
situated  on  a  building  roof,  some  40  to  45  feet  above  ground.  Height 
of  the  observer  is  an  important  factor  in  the  evaluation  of  ALWOS 
visibility  observations.  Later  discussion  will  address  this  aspect. 

4.1.?  Electronics 

The  CRT  display,  TI  745  printer,  and  processors,  etc.,  are  located 
inside  the  NWS  office.  Access  to  the  CRT  display  was  restricted  to 
only  those  personnel  involved  with  the  ALWOS  evaluation.  This 
excluded  the  NWS  observers  from  viewing  the  minute-by-minute  updates 
of  the  ALWOS  output  message.  Messages  on  the  745  printer  were  output 
well  after  the  times  when  they  could  have  biased  any  of  the  scheduled 
NWS  observations. 

The  CRT  display  and  voice  output  in  the  Dulles  tower  enabled 
controllers  and  other  FAA  personnel  to  keep  abreast  of  system 
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performance.  Additional  monitoring  was  performed  at  the  ISL  offices 
in  Silver  Spring,  Maryland,  and  at  the  FAA  in  Washington,  D.C.  from 
their  remote  telephone  data  drops. 

4 . 2  Data  Col  lection 

Hourly  and  Special  surface  observations  taken  at  the  Dulles  WSO  served 
as  standards  for  comparison  with  the  ALWOS  outputs.  In  addition, 
personnel  from  T&ED  would  take  supplemental  observations  when 
appropriate  to  further  establish  system  performance.  The  voice  output 
and  CRT  display  in  the  Dulles  tower  allowed  for  comments  on  system 
operation . 

4.2.1  ALWOS  and  WSO  Observations 

A  physical  science  technician  or  a  meteorologist  from  T&ED  would 
travel  to  the  Dulles  WSO  at  least  three  times  a  week  to  collect  data 
and  check  and  observe  system  operation.  During  each  visit,  the 
printout  of  ALWOS  observations  was  collected  from  the  printer  along 
with  copies  of  the  Dulles  surface  observations,  which  were  made  by  WSO 
personnel.  Normally  these  visits  to  the  WSO  were  scheduled  for 
Monday,  Wednesday,  and  Friday  of  each  week,  but  if  significant  weather 
occurrences  developed  additional  visits  were  made  to  observe  the 
response  of  the  ALWOS  system.  At  times,  meteorological  conditions 
wou  .  warrant  T&ED  personnel  remaining  at  the  WSO  for  the  greater 
portion  of  a  day. 

The  T&ED  oi'server  would  check  system  operation  in  several  ways: 

a.  Observe  the  minute-by-minute  updates  of  the  output  messages 
on  the  CRT  for  any  irregularities. 

b.  Look  for  any  unusual  periods  of  missing  data  in  the  current 
and  previous  observations 

c.  Call  up  the  account inq  mode  display  of  errors  on  the  CRT 
and  log  the  resu  1  tant  error  numbers. 

d.  Log  the  last  occurrence  of  system  power-up  time. 

Any  problems  noted  were  referred  to  ISL  for  discussion  and  appropriate 
corrective  measures. 

4.2.2  ALWOS  Output  Format 

Output  messages  from  ALWOS  are  printed  out  every  20  minutes.  The 
sample  message  below  illustrates  their  format  (Section  2.4  briefly 
touches  upon  message  format): 

lAD  ALWOS  06/22  2000  270VC  2  1/2  PB27E44 

(1)  (2)  (3)  (4)  (5)  (6)  (7) 

72/70/2809/967 
(8)(9)  (10)  (11) 

Note:  The  numbers  in  parentheses  below  the  message  are  used 
only  for  identification  of  message  parameters  for  this  report. 
They  are  not  output  in  actual  operation. 
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(1)  STATION  IDENTIFICATION:  (Dulles  International  Airport,  VA) 

Identifies  report  using  FAA  identifier. 

(2)  AUTOMATIC  STATION  IDENTIFIER 

(3)  DATE  OF  REPORT:  (June  22)  Month/day  is  reported. 

(4)  TIME  OF  REPORT:  GMT 

(5)  CLOUD  HEIGHT  AND  SKY  CONDITION:  (2700  ft.  overcast) 

Figures  are  height  in  lOO's  of  feet  above  ground. 

Symbol  after  height  is  amount  of  sky  cover. 

(6)  VISIBILITY:  (2  1/2  statute  miles) 

(7)  PRECIPITATION  AND/OR  THUNDERSTORM  OBSERVATIONS;  (Precipi¬ 

tation  began  at  1927  GMT  and  ended  at  1944  GMT). 

Figures  refer  to  minutes  after  the  hour.  P  indicates 
precipitation.  T  would  indicate  thunderstorm. 

(8)  TEMPERATURE:  (72  degrees  F) 

(9)  DEW  POINT:  (70  degrees  F) 

(10)  WIND  DIRECTION  AND  SPEED:  (280  degrees  at  9  knots) 

Direction  is  first  two  digits  reported  in  tens  of 
degrees.  The  last  digits  are  speed  reported  in 
actual  figures. 

(11)  ALTIMETER  SETTING:  (29.67  inches) 

The  tens  digit  and  decimal  are  omitted.  A  2  is 
prefixed  whenever  the  observation  begins  with  an 
8  or  9,  otherwise  a  3  is  prefixed;  e.g.,  017  =  30. 17. 

Other  possible  message  products  are: 

a.  Cloud  Height  and  Sky  Conditions  -  Partial  and  total 
obscurations  are  reported  as  -X  and  WX,  respectively. 

Up  to  3  cloud  layers  are  reportable.  The  maximum 
reportable  cloud  height  is  3000  feet.  If  there  are  no 
clouds  indicated  at  or  below  3000  feet  CLR  BLO  30  is  output. 

b.  Visibility  -  Whenever  visibility  is  determined  to  be  variable 
at  the  time  of  observation,  it  is  reported  at  the  end  of  the 
ALWOS  message  in  the  following  format: 

X  V  y 

X  =  lower  limit  of  variability  (in  miles) 
y  =  upper  limit  of  variability  (in  miles) 

For  example,  2  V  3  indicates  that  the  visibility  is  varying 
between  2  and  3  miles.  The  range  of  visibilities  reported  in 
the  ALWOS  message  runs  from  0  to  7  miles,  with  visibilities 
8  miles  or  more  reported  as  8+. 

c.  PreeipitationandThunderstorm  -  P  (precipitation)  or  T 

( thunderstorm)  is  output  when  the  event  is  determined  to  be 
occurring  at  the  time  of  observation. 

d.  Missing  Data  -  Missing  data  are  indicated  with  M's  in  the 
output  message . 

4.2.3  Dulles  WSO  Data  Format 

The  NWS  observers  at  Dulles  record  their  daily  surface  observations  on 
Form  MFl-10,  Surface  Weather  Observations,  Parts  A  and  B.  Figures  4-1 
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FIGURE  4-1.  FORM  MFl-lOA,  SURFACE  WEATHER  OBSERVATIONS 
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and  4-2  show  the  observations  for  September  1,  1981.  The  basic 
observations  consist  of  those  taken  hourly,  SA '  s ,  or  Specials,  SP's, 
which  can  be  taken  at  any  time.  Observations  are  made  in 
accordance  with  instructions  contained  in  Federal  Meteorological 
Handbook  (FMH)  No.  1-  Surface  Observations. 

4 . 3  Data  Analys  i  s 

Each  hourly  ALWOS  observation  was  entered  onto  a  blank  MFl-lOA 
form,  along  with  the  corresponding  WSO  observation,  to  form  a  daily 
comparison  log.  Although  the  Dulles  observation  is  completed  in 
advance  of  the  ALWOS  report  (generally  5-7  minutes  earlier),  the 
two  reports  can  be  considered  "simultaneous."  In  those  cases  where 
rapidly  changing  weather  conditions  resulted  in  obviously  differing 
observations,  appropriate  considerations  were  made  in  data 
analysis.  A  sample  portion  of  the  log  is  shown  in  Figure  4-3.  In 
column  1,  H  indicates  "human  observation"  (WSO)  and  A  indicates 
"ALWOS  observation."  Specials  (SP)  were  included  whenever  any  of 
the  ALWOS  observations,  including  those  not  "on  the  hour,"  differed 
in  time  within  approximately  the  same  number  of  minutes  as  the 
hourly  observations. 

As  a  means  for  comparing  the  WSO  and  ALWOS  observations,  a  table  of 
data  tolerances  was  formulated  based  on  consultations  among 
personnel  from  T&EO,  ISL,  and  the  FAA.  Figure  4-4  gives  the  ALWOS 
data  tolerances  with  respect  to  the  Dulles  observations.  As  the 
evaluation  proceeded,  these  tolerances  were  examined  for 
suitability. 

From  the  comparison  log,  the  frequency  of  observations  which  were 
"out  of  tolerance"  for  a  particular  parameter  was  determined. 

Those  observations  out  of  tolerance  were  analyzed  for  possible 
cause(s)  of  discrepancy.  Factors  such  as  instrument  and  observer 
siting,  prevailing  meteorological  conditions,  and  system  operation 
were  considered.  In  some  cases,  only  a  probable  cause  can  be 
advanced  for  discrepant  data.  Some  instances  pointed  to  easily 
discernable  factors.  In  any  event,  whenever  a  situation  warranted 
additional  investigation  the  circumstances  were  brought  to  the 
attention  of  ISL.  Regular  written  status  reports  were  provided  to 
ISL  and  the  FAA  during  the  evaluation  period. 

4 .4  Results 

Figure  4-5  indicates  the  number  of  discrepant  (according  to  the 
established  tolerances)  ALWOS  observations  by  month  and  for  the 
total  evaluation  period.  The  parameters  covered  are  sky  condition 
and  cloud  height,  visibility,  temperature,  dew  point,  wind 
direct  on,  wind  speed,  and  altimeter  setting.  Precipitation  and 
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FIGURE  A-3.  ALWOS  vs.  DULLES  OBSERVER  COMPARISON  LOG 
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Par ameter 

Tolerance 

Sky  Condition  and 

Cloud  Height 

+  500  ft.  and 
exact  descriptor 

Visibility 

1/4  mi .  ( 1/4-3  mi . ) 

1  mi .  (  3-8  mi . ) 

Temperature 

+  3  degrees  F 

Dew  Point 

+  5  degrees  F 

Wind  Direction 

+  30  degrees  (5  to  20  kts) 

+  20  degrees  (20  kts  and  up) 

Wind  Speed 

+  5  kts 

Altimeter  Setting 

+  .04"  Hg. 

Precipitation  and 
Thunderstorm 

exact  descriptor 

Figure  4-4.  ALWOS  DATA  TOLERANCES 


thunderstorm  observations  will  be  treated  separately.  A  large  number 
(4400)  of  observations  were  examined,  which  included  both  hourly  and 
special  reports.  The  numbers  in  parentheses  are  percentages.  For  sky 
condition  and  cloud  height,  a  discrepancy  was  counted  if  either  height 
or  the  descriptor  was  out  of  tolerance. 

Figure  46  gives  the  number  of  observations  which  were  output  as 
"missing."  Only  hourly  observations  are  included  here.  The  figures 
are  broken  down  into  two  main  types  of  category,  those  representing 
cases  where  the  entire  ALWOS  message  was  missing  (TOTAL  OBS  column) 
and  those  indicating  cases  where  partial  parameters  were  missing  (the 
rema i n i ng  col umns ) . 

Apart  from  cloud  and  visibility  observations,  the  number  of  discrepant 
reports  are  quite  low.  These  two  observations  are  among  the  more 
subjective  as  far  as  human  observations  are  concerned,  and  are  thus 
less  easily  compared  with  sensor-derived  information.  Other  factors 
w're  also  involved  which  contributed  to  the  greater  number  of 
discrepancies,  and  these  will  be  discussed  later  on.  The  numbers  in 
Figure  4-S  or  sky  condition  and  cloud  height  are  somewhat 
misleading.  A  great  proportion  (about  40%)  of  output  cloud  data  from 
ALWOS  was  "missing"  due  to  problems  with  the  ceilometer  (see  Figure 
4-6).  A  missing  report  was  not  counted  as  discrepant  data  but  was 
included  in  the  total  possible  observations.  If  the  missing  reports 
are  excluded,  the  percentages  of  discrepant  data  would  increase  to 
33%,  25%,  14%.  and  27%  for  uune  -  September,  respectively,  and  to  23% 
for  the  total  period. 

Amounts  of  data  reported  as  missing  from  ALWOS  were  also  small  (Figure 
4-6)  except  for  April  when  a  significant  number  of  complete 
observations  were  missing,  and  for  the  previously  mentioned  difficulty 
with  the  ceilometer.  A  complete  listing  of  system  and  sensor 
ma  1  f unc t  ions/ f a  i  1 ures  and  any  corrective  actions  taken  will  be  given 
in  Section  4.4.2  As  more  experience  with  tne  system  was  gained  and 
the  "bugs"  locoLed  and  corrected,  the  numbers  of  missing  complete 
observations  and  of  most  parameters  decreased  to  almost  nil  the  last  2 
months.  Overall,  the  percentage  of  complete  observations  missed  was 
only  3%  and  for  most  of  the  individual  parameters  2%  or  less.  The 
notable  exception  was  cloud  djta,  where  38%  of  the  total  hourly 
observations  were  missing. 

4,4.1  Parameter  Discussi  ns 

Each  parameter,  or  weather  element,  reported  by  ALWOS  will  now  be 
discussed  in  further  detail.  Emphasis  will  be  placed  o''  both  sensor 
performance  and  the  observational  algorithms.  The  intent  of  the 
evaluations  is  to  attempt  to  relate  the  discrepant  observations  to  a 
cause(s).  No  attempt  was  made  to  conduct  a  full  scale  sensor  or 
algorithm  evaluation,  except  where  out  of  tolerance  ALWOS  observations 
could  be  ascribed  to  these  areas.  Some  cases  of  discrepancy  were 
obviously  attributable  to  ■  easily  recognizable  cause,  but  others 
required  extensive  invest.  ions  which  were  beyond  the  scope  of  the 
evaluation.  In  these  instances  suggested  problem  areas,  solutions, 
etc.,  are  often  advanced.  The  ALWOS  outputs  are  compared  with  those 
prescribed  by  FMH#1  wherever  appropriate. 


DEWP 


ALT 


No:  ST?  CLOUD 

OBS  COND.&  HEIGHT*  VSBY*  TEMP 


WNT3  EJTNTJ 

DIR  SPEED 


March 

463 

- 

21(4) 

13(3) 

23(5) 

5(1) 

20(4) 

1(0) 

April 

603 

- 

94(16) 

9(1) 

161(27) 

10(2) 

15(3) 

1(0) 

May 

682 

- 

250(37) 

6(1) 

49(7) 

14(2) 

16(2) 

1(0) 

June 

716 

94( 19)** 

84(12) 

4(1) 

29(4) 

3(0) 

5(1) 

0(0) 

July 

717 

103(14)** 

121(17) 

2(0) 

3(0) 

5(1) 

6(1) 

0(0) 

Aug. 

816 

1 17(14)** 

123(15) 

5(1) 

1(0) 

15(2) 

2(0) 

0(0) 

Sept . 

403 

87(22)** 

107(27) 

1(0) 

1(0) 

7(2) 

1(0) 

0(0) 

Total 

4400 

401( 17)** 

800( 18) 

40(1) 

267  (  6  ) 

59(  1  ) 

65(  1  ) 

3(0) 

Note: 

*  Total 

numuer  of 

cloud  observations 

sampled 

included 

a  large 

proportion  of  missing  observations.  If  these  missing  observations  are 
exclude  ,  the  percentages  of  discrepancies  change  significantly  . 
Visibility  discrepancies  reflect  analysis  of  sensor  siting  and  other 
factors.  Further  details  are  given  in  the  appropriate  text  sections. 


**  Since  the  ALWOS  ceilometer  was  not  interfaced  into  the  system 

until  the  June  10,  2200Z  observation,  a  total  of  2424  observations 
were  involved,  which  included  488  in  June.  Percentages  are  based 
on  these  reduced  figures. 


FIGURE  4-5.  ALWOS  DATA  DISCREPANCIES 
(hourly  and  special  observations) 


POSSIBLE 

OBS 

nWL 

OBS 

SKY  &  CLOUD 
eOND.  HEIGHT 

VSBY 

TEMP 

DEWP 

WIND 

DIR 

WlND 

SPEED 

ALT 

March 

480 

9 

- 

1 

2 

2 

2 

9 

April 

720 

118 

- 

1 

10 

1  1 

7 

1 

6 

May 

744 

9 

- 

14 

28 

28 

24 

22 

1  9 

June 

720 

15 

203 

6 

3 

3 

1 

1 

1  3 

July 

744 

2 

273 

7 

24 

24 

27 

26 

Aug  . 

744 

0 

287 

5 

0 

0 

0 

0 

0 

Sept 

360 

0 

126 

1 

0 

0 

1 

0 

0 

Total 

4512 

153 

889 

35 

67 

68 

61 

50 

b  1 

Note:  Only  2330  total  observations  (specials  not  included)  were  possiole 

for  sky  condition  and  cloud  neight,  of  which  482  were  in  June. 


23  complete  observations  lost  when  output  printer  overprinted 
messages . 

19  complete  observations  lost  due  to  power  interruptions. 

10  complete  observations  lost  due  to  planned  system  shutdowns. 


FIGURE  4-6  MISSING  AND  PARTIALLY  MISSING  ALWOS  DATA 
(hourly  ob^trvations  only) 


4. 4. 1.1.  SkyCondltionandCloudHeight 

Overriding  data  collection  was  th^  excessive  number  of  missing 
observations.  The  cause  was  established  as  the  ceilometer's  response 
to  excessive  heat  buildup  in  its  electronics  as  the  outside  temperature 
increased.  Indeed,  the  missing  data  occurred  almost  exclusively  during 
the  daylight  hours.  Another  contributing  factor  might  have  been  the 
sun  affecting  the  sensor's  light  detector.  As  temperatures  began  to 
decrease  somewhat  in  September,  slightly  more  data  became  available. 

Figure  4-7  breaks  down  the  discrepant  ALWOS  cloud  observations.  The 
first  col  mn  indicates  the  number  of  observations  where  ALWOS  reported 
no  clouds  at  or  below  3000  feet  when  the  Dulles  WSO  reported  clouds. 

The  next  column  reverses  the  above  situation.  Next  are  the  number  of 
observations  where  both  ALWOS  and  Dulles  reported  clouds  and  where  the 
ALWOS  data  fei  outside  the  prescribed  tolerance  for  height  and/or  sky 
coverage  descriptor.  The  last  two  columns  indicate  the  number  of 
observations  where  Dulles  reported  an  obscuration  at  the  surface  and 
ALWOS  did  not  and  vice  versa. 

The  great  majority  of  cases  where  ALWOS  failed  to  detect  clouds 
occurred  whenever  there  was  a  reduced  visibility  condition  at  the 
surface  (precipitation,  fog,  haze).  This  tends  to  indicate  that  the 
laser  receiver  is  not  obtaining  enough  signal  to  detect  clouds.  In 
other  words,  the  visibility  phenomena  is  attenuating  the  laser  return. 
All  cloud  height  indicators  have  this  problem  to  some  extent. 

The  greater  tendency  for  ALWOS  to  report  surface  obscurations  may  be 
traced  to  differences  in  ALWOS  reported  visibilities  vs.  the  Dulles 
observer.  As  one  of  the  criteria  from  the  cloud  algorithm  (Appendix  A) 
for  determining  obscurations,  the  visibility  must  be  less  than  1  1/2 
miles.  Due  to  significant  differences  in  the  location  of  the  human 
observer  and  the  visibility  sensor,  the  ALWOS  system  tends  to  output 
lower  visibilities  in  certain  situations,  thus  contributing  to  the 
potential  for  more  obscurations.  There  were  also  cases  where  ALWOS 
reported  obscurations  with  visibilities  as  high  as  2  miles,  contrary  to 
the  algorithm  specification.  ALWOS  also  reports  "total  obscuration" 
much  more  frequently  than  "partial  obscuration."  Forty-eight 
observations  were  noted  over  the  June  -  September  period  where  Dulles 
reported  partial  obscuration  and  ALWOS  responded  with  total 
obscuration,  and  only  1  case  of  the  opposite  situation.  In  fact,  of 
the  176  ALWOS  obscuration  observations  only  7  were  partial  obscurations. 

Observations  where  both  ALWOS  and  Dulles  reported  clouds  at  or  below 
3000  feet  were  examined  to  get  a  fe^l  for  whether  the  discrepant  ALWOS 
reports  were  due  to  height,  sky  descriptor,  or  both.  The  results  are 
given  in  Figure  4-8.  Discrepancies  in  sky  descriptor  are  considerably 
more  common  than  those  for  cloud  height.  The  height  discrepancies  were 
split  about  evenly  as  to  whether  ALWOS  reported  lower  or  higher  heights 
than  the  Dulles  observer  (16  low  and  20  high  for  the  evaluation 
period).  However,  ALWOS  reported  less  cloud  amount  more  often  than 
greater  cloud  amount,  with  85  observations  and  39  observations, 
respectively.  Generally  there  was  only  one  sky  coverage  category 
difference  between  ALWOS  and  Dulles,  but  some  of  the  discrepant 
observations  (1335)  showed  a  two-category  difference.  An  example  of  a  2 
category  difference  would  be  ALWOS  reporting  a  scattered  (SCT)  sky 
condition  while  the  human  reports  overcast  (OVC)  conditions. 
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AtWOS  DULLES  HFIGHT  OR  ALWOS  DULLES 

MONTH  NO  CLOUDS  ■  NO  CLOUDS  DESCRIPTOR  NO  OBSCUR;  NO  OBSCUR. 


June  26  1  1  0  13 


July  20  2  36  21  24 


August  14  1  52  8  42 


September  17  1  55  4  10 


FIGURE  4-7.  ALWOS  CLOUD  DATA  DISCREPANCIES 
(For  clouds  reported  at  or  below  3000  feet) 
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FIGURE  4-8.  ALWOS  CLOUD  HEIGHT  AND  SKY  DESCRIPTOR  DISCREPANCIES 
(For  clouds  reported  at  or  below  3000  feet) 


4.4. 1.2  Visibilit 


The  interpretation  of  how  discrepancies  were  counted  should  be 
explained,  in  particular  how  visibilities  at  the  3  mile  "crossover" 
point  were  handled.  As  with  each  of  the  other  parameters,  the  lAO 
observation  is  considered  the  "standard".  If  the  human  reported  a 
higher  visibility  than  the  automated  ovservation,  then  the  following 
tolerances  were  in  effect  for  the  visibility  comparisons: 

human  visibility  is  1/4-3  mi.,  tolerance  is  +  1/4  mi. 

human  visibility  is  4-8  mi.,  tolerance  is  +  1  mi. 

Similarly,  if  the  human  observation  was  less  than  the  automated,  the 
following  tolerances  were  used: 

human  visibility  is  1/4  -  2  7/8  mi.,  tolerance  is  +  1/4  mi. 

human  visibility  is  3  -  8  mi.,  tolerance  is  +  1  mi. 

Analysis  of  visibility  observations  posed  some  special  problems. 

Based  upon  the  weather  situation  as  reported  by  the  Dulles  observer 
and  from  observations  taken  by  T&ED  personnel,  each  comparison 
observation  had  to  take  into  consideration  the  nature  of  the 
atmosphere  that  the  visibility  sensor  was  sampling  as  compared  with 
what  the  human  observer  was  viewing.  Since  the  sensor  was  essentially 
at  ground  level,  it  was  susceptible  to  conditions  near  the  surface 
(fog,  low  lying  moisture,  e.g.)  which  the  observer  could  see  over  or 
could  not  see  at  all.  Thus,  ALWOS  would  report  lower  visibilities  in 
these  instances.  However,  another  type  of  obscuration,  haze,  often 
resulted  in  higher  visibilities  being  reported  by  ALWOS.  Possible 
explanations  for  these  occurrences  could  be  decreased  sensitivity  of 
the  EG&6  sensor  to  haze  and  increased  vertical  extent  of  the  haze 
regime.  Examining  the  airport  transmi ssometer  data  aided  in  the 
determination  of  what  type  of  visibility  conditions  were  curring  at 
the  surface.  The  small  size  of  the  visibility  sensors  sampling  volume 
as  opposed  to  the  observer’s  large  field  of  view  is  another  major 
factor  to  consider  when  attempting  to  compare  observations.  The 
numbers  of  discrepant  observations  in  Figure  45  reflect  the  attempt 
to  analyze  the  above  factors.  If  strict  adherance  to  the  tolerance 
limits  set  at  the  beginning  of  the  test  were  followed,  the  figures 
would  look  worse  for  ALWOS.  The  total  number  of  discrepancies  then 
rises  to  27%.  Seventeen  percent  of  the  discrepancies  reflected  ALWOS 
visibilities  lower  and  10%  higher  than  the  observer. 

Two  significant  problems  surfaced  which  were  believed  to  be 
sensor-related.  Early  in  the  evaluation  period,  intervals  of 
considerable  disagreement  between  ALWOS  and  the  human  were  noted  when 
relatively  high  winds  (greater  than  20  knots)  with  gusts  (greater  than 
30  knots)  were  prevalent.  The  ALWOS  would  report  visibility  values 
much  lower  than  the  observer.  Before  and  after  the  periods  of  poor 
agreement,  wind  speeds  were  considerably  less.  It  was  observed  during 
these  windy  conditions  that  as  gusts  hit  the  sensor  and  the  sensor 
"arms"  were  shaking,  visibilities  would  lower.  This  apparent  wind 
effect  has  been  observed  with  the  same  type  of  sensor  at  T&ED  and  at 
the  Air  Force  Geophysics  Laboratory  (AFGL)  in  Massachusetts.  Though 
not  much  strong  wind  was  encountered  during  the  evaluation,  roughly  25 


observations  were  considered  bad.  Beginning  in  late  April  and 
continuing  in  May  completely  unrepresentative  observations  were 
output.  This  necessitated  the  replacement  of  the  sensor  with  another 
similar  unit.  Though  no  specific  cause  for  the  poor  obersvations  was 
found,  much  better  reports  were  noted  following  sensor  replacement. 
Roughly  275  discrepancies  in  April  and  May  were  attributed  to  this 
prob 1 em. 

The  ALWOS  system  responded  very  well  and  in  a  timely  manner  to  rapid 
changes  in  visibility.  Agreement  with  the  human  observer  in  such 
instances  was  quite  good.  In  some  instances,  the  ALWOS  responded  more 
quickly  than  the  observer  was  able. 

Other  noteworthy  aspects  of  ALWOS  performance  which  can  be  classified 
as  relating  to  the  algorithm/software  portion  of  the  system  are: 

a.  Some  totally  unrealistic  limits  on  "variable  visibility" 
have  been  reported.  As  an  example,  1/4V8  was  output  on 
April  30.  Though  the  fault  here  lay  with  erratic  sensor 
outputs,  some  form  of  quality  control  or  sensor  output 
damp ing  is  needed  to  avoid  such  false  informat  ion  going 
out  as  an  observation. 

b.  The  visibility  algorithm  (Appendix  B)  specifies  that  the 
limits  of  reported  variable  visibility  must  differ  by 
more  than  1/2  mile.  Cases  were  noted  where  ALWOS  was 
reporting  limits  of  less  than  1/2  mile  difference,  e.g., 
1  5/8  V  1  7/8. 

c.  ALWOS  does  not  add  a  "V"  in  the  output  message  after  the 
prevailing  visibility  whenever  visibility  is  variable 
(as  per  FMH#1). 

d.  When  the  reported  visibility  was  zero,  there  were  occa¬ 
sions  when  succeeding  visibility  observations  were 
reported  as  missing.  Only  11  observations  were  lost. 
This  flaw  has  been  identified  as  a  software  "bug". 

The  ALWOS  visibility  tolerances  were  reviewed  for  possible 
improvement.  Data  was  reexamined  with  the  tolerance  in  the  1  to  3 
mile  range  opened  to  1/2  mile  instead  of  1/4  mile.  Roughly  a  10% 
improvement  in  the  number  of  discrepant  observations  could  be 
expected.  No  other  changes  in  tolerance  were  considered  appropriate. 

4. 4. 1.3.  Precipitation  Occurrence 

Times  of  beginning  and  ending  of  precipitation  intervals  as  reported 
by  ALWOS  were  compared  with  those  reported  by  the  Dulles  observer.  As 
the  evaluation  proceeded,  many  false  indications  (over  300)  from  ALWOS 
were  noted.  Sensor  siting  proved  to  be  the  major  culprit.  The 
precipitation  Yes/No  sensor  was  located  on  the  roof  of  the  WSO 
building,  in  close  proximity  to  a  very  large  air  conditioning  unit 
which  was  housed  in  another  building.  As  part  of  the  cooling  process 
air  is  blown  through  circulating  water,  resulting  in  the  production  of 
numerous  droplets.  These  droplets  were  then  picked  up  by  the  wind  and 
often  deposited  on  the  precipitation  sensor,  causing  false  responses. 
This  necessitated  the  removal  of  the  sensor  and  relocation  to  the 
center  field  instrument 
site  in  early  July. 
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A  second  major  source  of  false  precipitation  indication  was  due  to  a 
clock  adjustment  tone  put  out  by  Dulles  Airport  at  around  56  minutes 
after  each  hour.  The  "noise"  from  the  tone  was  triggering  a  false 
sensor  indication.  Over  100  observations  were  affected.  A  circuit 
on  the  sensor  interface  card  was  designed  to  eliminate  the  false 
indications. 

Once  the  sources  of  erroneous  data  were  detected  and  the  associated 
problems  remedied,  a  clearer  picture  of  system  performance  was 
evident.  It  was  not  possible  to  totally  verify  many  cases  of 
precipitation  indication  without  having  an  observer  continuously 
monitoring  exactly  when  precipitation  began  and  ended  in  the  immediate 
vicinity  of  the  sensor.  Of  course,  this  approach  is  not  feasible  from 
a  manpower  standpoint.  Conclusions  and  significant  findings  will  now 
be  summarized: 


a.  The  sensor  generally  gives  an  accurate  indication  of 
rainfall.  Over  the  entire  evaluation  period  there  were 
8  instances  where  ALWOS  failed  to  detect  precipitation 
when  reported  by  Dulles.  However,  in  each  instance  only 
a  trace  of  precipitation  was  reported  by  the  observer  for 
the  total  precipitation  interval.  In  the  period  follow¬ 
ing  movement  of  the  sensor  to  center  field  and  after  the 
clock  tone  problem  had  been  resolved,  (from  about  mid- 
July  onward),  17  instances  of  false  precipitation 
indication  were  recorded.  Whether  these  were  due  to 
false  sensor  output  or  system  difficulties  could  not 

be  determined.  Some  cases  involved  only  one  minute's 
precipitation  duration.  The  NWS  Test  and  Evaluation 
Division  conducted  an  extensive  field  evaluation  of  the 
precipitation  sensor3  for  about  10  months  and  noticed 
a  negligible  number  of  false  sensor  hits.  Data  collec¬ 
tion  was  not  performed  in  an  automated  mode. 

b.  The  earlier  T&ED  evaluation  indicated  that  the  sensor 
performance  degrades  in  snow  as  opposed  to  rain.  In 
cases  of  snow  which  occurred  in  the  ALWOS  evaluation, 
the  human  reported  the  event  with  considerably  more 
accuracy  than  did  ALWOS. 

c  ALWOS  reported  the  beginning  of  precipitation  earlier 
than  the  WSO  observer  in  many  instances.  Though  impos¬ 
sible  to  verify  in  most  cases,  based  upon  the  T&ED 
evaluation  and  from  spot  checks  during  the  ALWOS  evalua¬ 
tion,  the  earlier  starting  times  are  probably  valid.  The 
sensor  is  capable  of  responding  to  individual  water  drops 
and  thus  can  accurately  indicate  the  initial  stages  of  a 
precipitation  event  which  may  not  be  detected  by  an  ob¬ 
server  in  some  instances.  No  pattern  was  noticeable  with 
respect  to  ending  times. 

d.  As  the  algorithm  is  written,  in  order  to  satisfy  the 
FMH#1  criterion  for  denoting  individual  precipitation 
periods  (at  least  15  minutes  between  intervals),  report- 


TI  Final  Report:  Evaluation  of  Mechanical  Precipitation  Occurrence 
Sensors,  T&ED  Division  Report  No.  2-80,  May  1980. 
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Ing  the  ending  of  precipitation  (the  last  sensor  indi¬ 
cation)  is  delayed  15  minutes.  Some  confusing  remarks 
are  the  result.  For  example,  if  the  last  sensor  indica¬ 
tion  occurs  at  1050Z,  the  program  would  wait  the  15- 
minute  period  before  reporting  and  would  then  report  PE50 
in  the  1120Z  ALWOS  observation  instead  of  in  the  normal 
(according  to  FMH#1)  llOOZ  hourly  observation.  The  PE50 
remark  would  then  be  carried  in  the  next  ALWOS  output 
message  (1140Z)  and  appear  in  the  1200Z  hourly  as  well, 
even  though  the  precipitation  ended  1  hour  and  10  min¬ 
utes  earlier.  A  remark  could  be  output  at  1200Z  such  as 
PE50B20  where  the  PESO  would  actually  stand  for  1050Z  and 
the  B20  for  1120Z. 

e.  Whenever  precipitation  remarks  were  reported  in  an  hourly 
ALWOS  observation  (e.g.,  PB20)  and  precipitation  was 
occurring  at  the  time  of  the  observation,  a  "P"  was  not 
output . 

f.  Infrequently  a  precipitation  interval  would  have  either 
the  beginning  or  ending  time  remark  absent  from  the 
appropriate  ALWOS  observation. 

4. 4. 1.4  Thunderstorm  Occurrence 

Analysis  of  thunderstorm  occurrence  as  reported  by  ALWOS  was  limited 
in  many  instances  due  to  the  capabilities  of  the  lightning  detector. 
Since  the  sensor  is  capable  of  detecting  lightning  beyond  the  visible 
and  audible  range  of  the  observer  at  Dulles,  comparing  ALWOS  vs. 

Dulles  observations  on  a  one-to-one  basis  was  impossible.  This 
increased  sensor  capability  (out  to  about  50  miles)  was  determined 
from  an  evaluation  of  the  same  sensor  at  T&EO^.  Many  cases  arose 
where  ALWOS  reported  thunderstorm  activity  and  the  Dulles  observer  did 
not,  as  well  as  numerous  instances  where  ALWOS  reported  earlier 
beginning  and  later  ending  times. 

In  order  to  reconcile  this  potential  problem,  radar  reports  from  the 
NWS  Patuxent  River  radar  were  examined  and  ALWOS  thunderstorm  reports 
evaluated  accordingly.  The  reports  consisted  of  verbal  and  coded 
messages  received  on  teletype  at  T&ED.  However,  some  reports  could 
not  clarify  whether  the  lightning  detector  was  giving  a  valid 
indication  or  responding  to  electronic  "noise"  or  some  other 
triggering  mechanism. 

The  T&EO  evaluation  showed  that  the  sensor  was  indeed  quite 
susceptible  to  such  "noise",  which  resulted  in  false  lightning 
indications.  During  the  Dulles  evaluation  through  June,  there  were 
114  instances  of  false  indication.  However,  from  July  1  through 
September  15  only  3  such  cases  were  noted.  No  specific  cause  could  be 
found  for  the  improved  performance. 

In  only  one  instance  did  the  ALWOS  fail  to  detect  a  thunderstorm  event 
when  reported  by  the  human  observer. 


T!  Evaluation  of  the  Atlantic  Scientific  Lightning  Warning  System 
FCM-1,  T&EO  Division  Report  No.  1-80,  January  1980 
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According  to  FMHil.  a  thunderstorm  is  considered  to  have  ended  15 
minutes  after  the  last  determined  occurrence.  This  ensures  that 
thun  erstorm  events  will  last  at  least  15  minutes.  The  ALWOS 
algorithm  does  not  make  provision  for  such  reporting  and  often 
thunderstorm  intervals  were  less  than  15  minutes.  As  a  result, 
remarks  such  as  TB05  ElO  were  reported  by  ALWOS. 

4. 4. 1.5  Temperature 

Few  discrepant  observations  were  reported  by  ALWOS.  No  additional 
comments  are  necessary. 

4 . 4  . 1 . 6  Dew  Po int 

A' WOS  dew  points  presented  a  problem  early  in  the  evaluation  period, 
particularly  in  April.  A  significant  number  of  ALWOS  observations  had 
fallen  out  of  the  tolerance  limit,  on  the  low  side,  and  were  not 
consistent  with  the  synoptic  weather  situation.  For  example,  during 
fog  episodes  the  dew  point  spreads  (the  difference  between  the  ambient 
temperature  and  dew  point  temperature)  reported  by  the  Dulles  observer 
were  often  2  degrees  or  less,  appropriate  values  for  fog  conditions. 
The  ALWOS  would  report  dew  point  spreads  of  5-7  degrees  which  are 
unrepresentative  of  fogs. 

The  dew  point  bobbin  assembly  had  to  be  replaced  twice  to  correct  the 
deficiency.  After  the  last  repl aacement ,  in  early  May,  readings 
became  much  mor-  consistent  and  within  tolerance  for  the  great 
majority  of  remaining  observations. 

4 . 4 . 1 . 7  Wind  Direction  and  Speed 

Both  parameters  were  reported  by  ALWOS  with  few  discrepancies.  Cases 
where  winds  were  "light  and  variable"  were  not  considered  in  the  ALWOS 
vs.  Dulles  comparisons.  As  defined  by  FMH#1,  "light  winds  are  those 
where  the  wind  speed  is  6  knots  or  less,  and  a  "variable"  situation 
exists  when  the  wind  direction  fluctuates  by  60  degrees  or  more  during 
the  period  of  observation. 

4. 4. 1.8  Altimeter  Setting 

Altimf'ter  setting  was  the  most  consistent  and  accurate  parameter 
measured  by  ALWOS.  Only  3  observations  were  out  of  tolerance. 

4.4.2  System/Sensor  Problems 

In  Figures  4-9  and  4-10  the  significant  ALWOS  malfunctions/"bugs" 
which  surfaced  during  the  evaluation  period  are  listed  in 
chronological  order.  Each  item  is  described  as  to  date  first  observed 
or  reported,  the  nature  of  difficulty,  and  any  corrective  measures 
taken.  Problems  are  grouped  according  to  whether  they  were  system 
(data  acquisition,  software,  algorithms,  etc.)  or  sensor-related. 

The  majority  of  missing  or  invalid  data  is  accounted  for  by  the 
failures  indicated  in  the  two  listings.  "Analog  to  digital"  (A/D) 
errors  were  the  major  sources  of  poor  or  missing  data.  The  number  of 
sensor  difficulties  was  minimal,  but  most  cases  involved  a  serious 
degredation  or  loss  of  ALWOS  data  which  required  replacement  of  faulty 
sensors . 
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FIGURE  4-9.  ALWOS  SYSTEM  MALFUNCTIONS 


3/17/81  Low  visibilities  output  during  high  Installed  bolt  holding  sensor  on  its  stand 

winds  (with  gusts)  due  to  shaking  but  sensor  apparently  was  still  vulnerable  to 

of  sensor  "arms"  high  wind  conditions 
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FIGURE  4-10.  ALWOS  SENSOR  MALFUNCTIONS 


5.  SUMMARY  AND  CONCLUSIONS 


An  ALWOS  system  located  at  the  Dulles  International  Airport  was 
evaluated  for  a  six-month  period  under  operat ional -type  conditions. 
Observations  output  from  ALWOS  were  compared  with  official  NWS 
observations  taken  at  the  Dulles  WSO.  The  weather  parameters  observed 
included  sky  cond i t i on/c 1 oud  height,  visibility,  temperature/dew 
point,  wind  speed/direction,  altimeter  setting,  precipitation 
occurrence,  and  thunderstorm  (lightning)  occurrence.  Comparison  with 
NWS  data  was  generally  limited  to  the  regular  hourly  observations 
taken  at  Dulles.  Those  parameters,  as  reported  by  ALWOS,  which  were 
outside  of  prescribed  data  tolerance  limits  were  examined  for  the 
cause(s)  of  discrepancy. 

Based  on  the  field  evaluation  of  the  ALWOS  system,  the  following 
points  should  be  emphasized: 

a.  The  ALWOS  as  configured  at  Dulles  Airport  is  a  workable 
system  which  can  provide  an  automatic  weather  observation 
from  the  data  acquisition,  processing  and  display  point  of 
view,  with  the  potential  for  good  long-term  system  reli¬ 
ability,  After  a  period  of  familiarization  with  the 
equipment  and  dealing  with  an  assortment  of  system  and 
sensor  problems,  the  functioning  of  the  system  became 
relatively  trouble-free.  Problems  with  A/D  data  conversion 
were  reduced  to  minimal  levels  during  the  latter  months  of 
the  evaluation. 

b.  Evaluation  of  the  ALWOS  supports  the  already  generally 
accepted  concept  that  automated,  low-cost  weather 
observation  systems  can  indeed  perform  such  a  function 
given  suitable  sensing  devices.  Though  printed  as  a 
hard-copy  message  every  20  minutes,  ALWOS  information 
was  provided  also  in  one-minute  update  form,  including 
"voice"  output,  which  lends  itself  to  automated  applica¬ 
tion. 

c.  Performance  of  some  of  the  various  ALWOS  sensors 
reinforces  the  important  and  still  basically  unfulfilled 
need  for  suitable  instruments  which  can  supply  informa¬ 
tion  that  can  be  successfully  incorporated  into  an 
automated  observing  scheme.  This  is  particularly  true 
for  cloud,  visibility,  and  thunderstorm  detection  data. 

The  Impulsphysik  prototype  ceilometer  was  unacceptable 
due  to  its  consistentlylarge  output  of  missing  data. 

The  EG&G  visibility  sensor  suffered  from  a  period  of 
serious  unreliability  (which  eventually  required 
replacement  of  the  sensor).  Atlantic  Scientific's 
lightning  detector  as  designed  was  unsuitable  for  human 
vs.  machine  comparisons  and  also  displayed  a  high  false 
alarm  rate,  at  least  during  the  early  months  of  the 
evaluation.  Finally,  the  YSI  dew  point  element  (bobbin) 
requ i red  rep  1 acement  to  correct  consistently  low 

read i ngs . 

d.  Temperature,  wind  direction/speed,  and  altimeter  setting 
observations  were  usually  within  tolerance  limits.  When 
the  sensor  was  operating  properly,  dew  point  temperatures 
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also  were  generally  within  tolerance.  Precipitation  Yes/ 
No  was  handled  reasonably  well  by  the  Wong  Laboratories 
grid  sensor.  With  proper  sensor  operation,  reported 
ALWOS  visibilities  showed  reasonable  agreement  with  the 
human  observer  in  many  instances,  but  sensor  location 
introduced  a  source  of  significant  disagreement  under 
certain  visibility  conditions. 

e.  It  was  not  within  the  scope  of  the  evaluation  effort  to 
thoroughly  review  the  performance  of  the  parameter 
algorithms.  Algorithms  were  examined  to  the  extent  where 
discrepant  ALWOS  observations,  inconsistencies  in 
reporting,  etc.,  were  caused  by  the  algorithms  them¬ 
selves  or  the  manner  in  which  the  algorithms  were 
programmed  into  the  system.  Such  determinations  have 
been  described  in  earlier  sections  of  this  report. 

Two  algorithms,  for  clouds  and  visibility,  have  had 
considerable  review  and  testing  performed  on  them  in 
other  automated  systems  and  are  included  in  Appendices 
A  and  B,  respectively.  Other  algorithms,  for  example 
those  for  precipitation  and  thunderstorm  occurrence, 
have  received  less  scrutiny. 

1 
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APPENDIX  A 


ALWOS  CLOUD  ALGORITHMS 


^  A0-A117  AA7  national  HEATHER  SERVICE  SILVER  SPRING  MQ 

automated  loh-cost  Heather  observation  system  (almos).(U) 
FEB  62  H  HUFFMAN*  S  IMBEMBO 


unclassified 


OOT/FAA/RO-S2/31 


ALUOS  CLOUD  ALGORITHMS 


CLOUD  BASE  HEIGHT  ALGORITHM 

I 

AUTOB  ALGORITHM  (Revised) 


October  1,  1980 


Cellomeier  CPU  Description 


The  following  is  a  description  of  the  Ceilometer  CPU  that 
will  operate  in  the  ALWOS  System.'  The  Ceilometer  CPU  accepts  the 
Impulsphysic  ceilometer  data  and  outputs  cloud  cover  via  the 
ceilometer  CPU  soHware.  The  CPU  software  is  made  up  pf  the 
AUTOB  algorithm  modified  to  work  with  the  Impulsphysics 
ceilometer.  The  major  modification  to  the  AUTOB  algorithm  is  in 
Cloud  Height  Algorithm  which  is  described  next. 

Cloud  Base  Height  Algorithm 

Description;  This  module  is  entered  from  the  AUTOB  Algorithm 
which  has  been  modified  for  ALWOS.  The  Cloud  Base  Height 
Algorithm  accepts  the  data  from  the  Impulsphysic  Ceilometer  which 
consists  of  65  words.  The  first  and  last  words  are  start  and 
stop  codes,  words  two  and  three  are  status  words,  and  the 
remaining  61  words  contain  the  backscattcred  energy.  These  words 
in  position  4-64  inclusive  correspond  to  range  bins  100-150  feet 
to  3100-3150  feet  (n«4  to  n=64).  Each  word  consists  of  8  bits  or 
one  byte  and  can  vary  from  0  to  255.  The  backscattered  energy 
data  d^  ,  in  the  n*^  range  bin,  is  offset  by  13  in  the  hardware. 
Let  D^>d^  -13  where  now  consists  of  signals  plus  noise  E^  , 
0^»S^+E^.  The  noise  in  each  range  bin,  E^,  is  drawn  from  a 
normal  population  with  mean  0  and  variance  where  is 


the  number  of  laser  pulses  summed  to  form  the  estimate  of  D^and 
is  the  noise  variance  for  a  single  pulse.  (Note  that  N.,^ 

'  ,  I 

increases  with  n  to  make  up  for  the  1/R  range  loss).  Thus  ^  or 
is  an  estimator  of  ^  N.o^-o;  We  observe  signal  plus 

*n«4  ’*  <^.4^  ^ 

noise.  Since  S.^is  always  positive,  if  one  forms  th^  partial 


sums  from  each  range  bin  m  for  which  0.y^is  negative,  then  a 

»  a  2 

conservative  (small)  estimator  of  <r^\  is  er,  «  ^  /  £  N^  . 

4  4 

The  ratio  (0.^  -1  )/^»(D.^ -1  )/n  o',  *R^  is  then  formed,  with  the 
understanding  that  n  s:  hJ^.  If  R^-2.0,  which  is  to  say  that  the 
corresponding  0^  is  two  or  more  standard  deviations  above  the 
noise,  for  three  or  more  successive  n‘s,  then  choose  the  first 
bin  where  R.,.-?  as  the  cloud  base  height. 


Ceilometer  CPU  Memory 

The  ceilometer  algorithm  as  implemented  uses  the  AUT06 
algorithm  preceded  by  the  Cloud  Base  Height  algorithm  previously 
described.  The  AUTOB  algorithm  is  documented  in  "AUTOB  Algorithm 
#2"  and  will  not  be  described  here.  The  AUTOB  algorithm  was 
developed  before  we  had  the  Intel  development  systems,  and  is  not 
relocatable.  The  code  for  AUTOB  is  not  memory  compatible  with 
the  8020  Intel  CPU  board.  Two  alternatives  to  correct  this 
problem  were  to  either  type  2.5K  of  code  into  the  MDS,  including 
reassignment  of  subroutines  previously  in  absolute  addresses,  or 
rearrange  the  8020  board  memory  to  be  compatible  with  AUTOB.  The 


latter  approach  was  taken.  The  decision  was  made  because  It  would 

be  time  consuming  to  re-dcbug  the  AUTOB  algorithm  after  a  lengthy 

conversion.  The  memory  rearranging  required  placing  the  8020  RAM 
« 

at  1000H  Instead  of  3000H  and  placing  the  AUTOB  algorithm  and  the 
Cloud  Base  Height  algorithm  In  the  absolute  code  areas  of  0  to 
OFFFH  and  1  BOOH 'to  1FFFH,  RAM  memory  being  at  1000H  to  17FFH. 

This  was  accomplished  quite  painfully  since  It  required 
relocating  some  of  the  floating  point  by  hand.  The  following  Is 
a  memory  map  of  the  Cellometer  CPU. 

0000  to  09FFH  AUTOB  Algorithm  tZ 

OAOOH  to  OEDOH  Cloud  Base  Height  Algorithm 

0EF8H  to  OFFFH  Floating  Point 

lOOOH  to  17FFH  RAM 

1800H  to  1FFFH  Floating  Point 

The  AUTOB  algorithm  has  been  slightly  modified  for  ALUOS. 
These  Include  modifications  of  the  Baudot  codes  to  ASCII  codes, 
modification  of  the  Inputting  of  visibility  and  outputting  of 
cloud  cover,  and  addition  of  special  status  and  control  codes. 
These  changes  are  described  elsewhere  In  this  document. 


Ceilometer  CPU  Interfacing 

The  Ceilometer  CPU  accepts  data  from  the  Impulsephysic 
Ceilometer  at  110  baud,  RS232  format.  The  signal  is  input  on 
J3-4  and  gnd.  The  signal  occurs  every  28  seconds  ano  consists  of 
65  words. 

The  remaining  interfacing  to  the  CPU  card  is  accomplished 
via  the  multibus.  The  CPU  inputs  visibility  data  from  the  main 
CPU  and  outputs  cloud  cover  data  to  the  main  CPU.  The  visibility 
data  is  stored  at  location  832AH  by  the  main  CPU,  busy/done  logic 
is  not  required  for  this  transfer  because  it  is  a  one  instruction 
store  by  the  main  CPU.  The  visibility  is  stored  as  a 
"displacement  number"  defined  as  follows: 


-15: 

visibility 

«  1 

1/2  miles 

<15: 

visibility 

>  1 

1/2  miles 

>15: 

visibility 

1  1/2  miles 

-FFH: 

visibility 

is 

missing 
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Celloroeier  CPU  Error  Messages 
As  mentioned  previously  the  first  word  In  the  stored 
cellometer  message  Is  either  01  or  02.  The  02  Indicates  that 
the  cellometer  message  that  follows  Is  good.  An  01  indicates 
that  the  cellomet'er  Is  not  working  due  to  any  one  of  the 
following  conditions: 

-  The  laser  power  is  not  within  60  ^  10%  of  Its 
maximum  output  power. 

>  The  laser  Is  not  outputting  a  message  at  least 
every  40  seconds. 

-  The  data  In  the  61  backscattered  energy  bins  has 
no  negative  numbers  or  that  no  noise  Is  present 
in  the  cellometer  signal. 

In  all  of  the  above  conditions  the  CPU  will  not  lockup  in 
the  error  mode.  Should  any  of  the  error  conditions  corr^x^t 
Itself  the  CPU  will  continue  to  develop  a  cloud  message. 


Cloud  Base  Height  Algorithm  Subroutines 
The  Cloud,  Base  Height  algorithm  (CBH  algorithm)  uses 
subroutines  to  input  data  from  the  DART,  check  data  start  and 
complete  codes,  and  check  data  quality.  These  subroutines  are 
annotated  in  the ‘program  listing  and  further  explanation  here 
would  be  redundant.  The  major  subroutines  used  in  the  CBH 
algorithm  are  the  Floating  Point  Arithmetic  Library  or  FPAL. 
This  is  a  software  package  provided  by  Intel.  The  operations 
used  are  addition,  multiplication,  division,  value  comparison, 
and  conversion  from  decimal  to  floating  point  numbers.  All 
operations  are  single  precision  with  a  range  of  1.2xl0'^*  to 
3.4x10  ,  using  a  32  bit  format.  The  details  of  FPAL  can  be 

found  in  the  Intel  manual  entitled  "8080/8085  F1oating>Point 
Arithmetic  Library  User's  Manual." 


Call  from  the  AUTOB  algorithm 


Initialize  the  stack,  setup  UART,  general  housekeeping 

Look  for  start  character  from  cellometer,  lock  onto  data 
stream 

Check  laser  power  within  limits  of  60  ♦  10%,  If  out  of 
limits,  place  01  In  place  of  02  at  message  start 

Input  61  bins  of  data  In  CBUF  buffer,  data  stored  Is 
minus  the  13  offset.  Store  negative  data  In  HBUF 
followed  by  bln  number  corresponding  to  negative  number. 


Take  the  sum  of 


the  squared  negative 

t.  < 

'»n»4 


numbers  In  KBUF 


Convert  the  bln  number  stored  In  MBUF  to  number  of 
samples  In  that  bln.  Sum  number  of  hits  for  all  of 
negative  numbers 


A  I  'A 

-  Form  the  estimated  noise  o;  N^| 

ITM  j 

t 

which. is  defined  as  SIG.  The  square  root  of  a  number 
is  determined  by  iterating  the  expression 

n»l,2,3,...  until  sufficiently  small,  or  in 

other  words,  until  x^.  is  a  satisfactory  approximation 
to  X  *  (x*)'^^.  As  an  initial  guess,  x,  *  1. 

Determine  the  number  of  standard  deviations  above  the 
noise  (0^-l)/(n  SIG)  for  each  bin 

-  If  the  number  of  standard  deviations  t  2  for  three 
successive  bins,  record  the  magnitude  of  the  third 
standard  deviation  and  first  cloud  height  where  the 
standard  deviation  2  2. 

•  Add  96H  to  the  cloud  height  value  to  be  compatible  with 
AUTOB  algorithm  and  return  to  AUTOB  algorithm. 
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AUTOB  DESIGN  ALGORITHM  #2 


March  31.  1977 


Observation  Techniques  Development  &  Test  Branch 
Test  and  Evaluation  Division 
Sterling.  Virginia 


REVISED  FOR  ALWOS  SEPTEMBER.  1980 
Equipment  Development  Laboratory 
Silver  Spring.  Maryland 
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AUT06  DESIGN  ALGORITHM  12 


This  updated  algorithm  Is  Intended  to  replace  the  AUTOB  cloud 
algorithm  presently  In  use  at  Summit^  Alaska;  Wendover,  Utah; 
and  SR&OC,  Virginia.  It  recognl2es  the  current  limitations  and 
constraints  on  programming,  computer  sl2lng,  and  hardware  as 
discussed  by  T&ED,  OSD.  and  EDL  at  the  AUTOB  meeting  on  March 
25,  1977. 

The  Inputs  to  the  algorithm  are: 

1.  Impulspbysic  laser  cellometer 

2.  Sensor  Equivalent  Visibility 
The  operating  conditions  are: 

Clouds 

1.  The  Impulsphysic  laser  cellometer  will  be  the 
cloud  sensor. 

2.  Input  to  the  algorithm  will  be  dig1ti2ed  back- 
scattered  energy  for  each  50  foot  range  bln  and  a 
total  range  of  100  to  3100  feet. 
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3.  One  total  range  scan  every  28  seconds  will  be  used. 

4.  Update  cloud  Information  approximately  every  4 
minutes . 

5.  There  will  be  only  one  cloud  height  (lowest  re¬ 
turn)  each  scan. 

6.  Any  cloud  return  below  100  feet  will  be  rejected 
as  a  "no  hit". 

7.  Upper  limit  of  cloud  returns  will  be  3000  feet. 

M  1  f  ty 

1.  Visibility  (sensor  equivalent  visibility)  is  de¬ 
rived  from  the  ALWOS  visibility  algorithm  (de¬ 
scribed  in  a  separate  document). 

2.  An  Indication  of  present  visibility  below  1  1/2 
miles  is  used  as  input  to  the  cloud  algorithm. 
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NOTES: 


1.  Data  from  the  cloud  algorithm  and  the  backscatter 
visibility  module  are  nonsynchronous.  (This  will 
'occasionally  cause  an  obscuration  to  be  reported 
with  a  present  visibility  of  2  or  more  miles). 

2.  Each  sample  is  counted  as  three  samples  when  it  is 
entered  in  the  AUTOB  algorithm.  This  is  done  to 
account  for  the  slower  data  rate  of  the  Impul- 
sphysic  ceilometer  as  compared  to  the  Rotating 
Beam  Ceilometer  (RBC).  This  results  in  fifty 
actual  data  points  (ISO  data  points  when  counted 
three  times)  over  a  period  of  approximately  23 
minutes  being  used  to  compute  cloud  cover. 


i 
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AUTOB  DESIGN  ALGORITHM  12 


PROCESSING  SEQUENCE 

1.  From  the  Impulsphysic  laser  ceilometer.  retain  a  tine 
ordered  sequence  In  such  a  way  that  a  running  23  min¬ 
ute  sequence  of  strikes  Is  available  on  demand  for  pro¬ 
cessing. 


2.  Sample  the  cellometer  every  26  seconds  for  23  minutes. 
There  will  be  only  one  cloud  height  (lowest  return)  per 
scan. 


3.  Convert  each  sample  to  cloud  height  in  feet.  Cloud  hits 

reported  as  above  3000  feet  are  to  be  considered  as  no  hits. 


Recency  weighting.  Give  double  weight  to  each  scan  in  last 
1/3  of  sample  Interval  (e.g.  last  10  minutes).  That  is  If 
there  are,  say,  hits  within  the  last  10  minutes  at  2500, 
2550,  and  2800  feet,  we  would  consider  them  to  be  2500, 

2500,  2550,  2550,  2800,  and  2800.  Likewise,  "no  hits"  would 
also  have  double  value.  Total  possible  hits  are  thus  three 
times  the  total  cellometer  scans  plus  total  scans  In  last 
1/3  of  sample  period.  (E.g.  for  23.3  min.  we  have  50 
scans  x3  (each  scan  weighted  3  times)  plus  50  ■  200  scans 
or  possible  hits.)  These  double  weights  are  to  be  carried 
through  remainder  of  program. 
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5.  Bln  each  saaple  hit  to  nearest  100  feet. 

6.  If  cloud  hits  are  present  In  more  than  5  bins,  use  Cluster 
Subprogram  In. attached  supplement.  Output  consists  of 
cluster  heights  and  number  of  hits  In  each  cluster.  Go  to 
Step  8  of  algorithm. 

7.  If  hits  are  confined  to  5  bins  or  less,  go  directly  to  com¬ 
bine  subprogram.  Each  bln  will  now  be  considered  an  In¬ 
dividual  cluster.  Output  consists  of  cluster  (bln)  heights 
and  number  of  hits  In  each  cluster. 


6.  Combine  Subprogram: 

a.  Order  all  clusters  from  lowest  to  highest. 

b.  Start  from  lowest  cluster  and  search  upward. 

c.  If  two  clusters  fit  the  following  table: 

Lower -Cluster  Height  Higher  Cluster  Within 

Surface  to  500  feet 
SOO  to  2000  feet 
2000  to  3000  feet 


♦  150  feet 

♦  250  feet 

♦  350  feet 

of  lower  cluster  height 


A-IB 


Then  we  would  combine: 

• 

d.  Combine  by  taking  the  height  of  the  lower  cluster  times 
the  number  of  hits  in  that  cluster  plus  the  height  of 
the  higher  cluster  times  the  number  of  hits  in  that 
cluster  and  divide  total  by  the  sum  of  the  number  of 
hits  in  both  clusters. 

(e.g.  (aN+bM4cH  )/(N  +  M  4  H  )).  This  value  is 
now  our  new  cluster  height  value»  and  (N  4  M  4  H  )  is 
number  of  hits  in  that  cluster. 

e.  Once  two  clusters  have  been  combined,  they  cannot 
be  separated  and  are  to  be  considered  a  new  cluster 
which  will  be  placed  in  the  proper  sequence  of  re¬ 
maining  clusters. 

f.  Cycle  until  all  possible  clusters  are  combined. 

9.  Each  cluster  with  more  than  5  hits  is  considered  a  layer. 

Each  cluster  with  5  or  less  hits  and  whose  ascribed  height 

Is  lower  than  the  lowest  cluster  with  more  than  5  hits  is 

« 

r 

not  considered  anylfurther  in  the  program  and  Its  number  of 

I 

hits  Is  not  added  to  any  other  cluster.  For  those  clusters 
with  5  or  less  hits,  and  whose  ascribed  height  Is  higher 
than  a  cluster  with  more  thpn  5  hits,  these  clusters  are 
not  considered  any  further  but  their  hits  are  added  to  the 
next  higher  cluster;  however,  the  highest  cluster  will  be 
considered  a  layer  even  with  only  one  hit. 
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10.  For  ea:h  assigned  height  value  round  to  the  nearest  100 
feet. 

11.  For  each  cluster,  divide  number  of  hits  in  that  cluster  by 
total  possible  hits.  Assign  this  result  to  R(l)  for  each 
respective  cluster.  The  cumulative  frequency  ratio  (CR) 
will  be  summation  of  the  R(l)'s  up  to  cluster  (1). 

12.  Output  shall  consist  of  standard  information  on  cloud 
condition.  This  output  group  will  be  one,  two,  or  three 
statements  of  sky  conditions  as  follows: 

a.  CLR  BLO  30  if  less  than  .05  cumulative  fre> 
quency  ratio  (CR)  exists  for  all  height 
ranges  and  output  is  not  modified  by  Step  13. 

b.  If  any  height  range  (layer)  has  a  cumulative 
frequency  ratio  (CR)  of  .05  or  higher,  cal¬ 
culate  hchcScScSc  for  each  layer  having  a 
cumulative  frequency  ratio  of  .05  or  higher, 
where:  hchc  ■  cloud  heights  to  nearest  report- 
able  Increment  as  determined  above  and  SeSeSe 
Is  one  of  the  following  contractions: 

SCT,  BKN,  or  OVC  where: 


m 


SCT  ■  a  cumulative  frequency  ratio  of 
.05  to  <.55 

« 

BKN  *  a  cumulative  frequency  ratio  of 
.55  to  <  .87 

.'OVC  •  a  cumulative  frequency  ratio  of 
>  .87 

c.  The  output  group  shall  consist  of  one.  two.  or  three 
statements  of  sky  conditions  starting  with  the  lowest 
such  height  range  as  follows: 

hchcScScSc  hchcScScSc  hchcScScSc 

The  following  priorities  shall  be  used  in  determining 
which  of  one.  two,  or  three  height  ranges  will  provide 
data  for  the  standard  group: 

(1)  The  lowest  height  range  for  which  the  (CR) 
equals  or  exceeds  .05. 

(2)  The  lowest  height  range  at  which  the  (CR) 
equals  or  exceeds  .55  if  different  from  (1) 
above. 

(3)  The  lowest  height  range  at  which  the  (CR) 
equals  or  exceeds  .87  If  different  from 
above. 
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(4.)  The  second  lowest  height  range  where  (CR) 

is  greater  or  equal  to  .05  and  less  than  .87. 

(5)  The  highest  height  range  where  (CR)  Is  greater 
or  equal  to  .05  and  less  chan  .87. 

(6)  A  second  (higher)  overcast  (CR  .87)  Is  not 
reported.  However  the  remark  HIR  CLDS  VSBL  Is 
output  at  the  end  of  the  AUTOB  message. 

13.  If  the  visibility,  as  furnished  from  elsewhere  In  the  pro¬ 
gram,  Is  less  than  1  1/2  miles,  scan  last  10  minutes  of 
cloud  data. 

a.  If  there  are  less  than  5  hits  In  the  last  10  minutes 
disregard  the  computations  In  Step  12,  and  output  as 
the  sky  condition: 

WX. 


b.  If  there  are  5  or  more  hits,  prefix  cloud/cover 

amount  with  -X.  Also  add  .6  cloud  coverage  to  lowest  . 

(and  subsequent)  cloud  layers  generated  by  program 

and  recompute  ^loud  layer  amounts.  Recompute  and  re- 
»■ 

label  cloud  layer  designations  (SCT,BKN)  with  new 
•• 

factor  of  .6  added.  * 


c.  If  the  output  from  Step  12  is  CLR  BLO  30  ,  change  this 
output  to  read  -X. 


14.  a.  When  It  has  been  determined  which  cloud  data  are  to  be 

reported,  these  data  will  be  ordered  In  the  value  of 
hchc  starting  with  the  lowest  hchc  value. 

b.  For  lowest  BKN  or  OVC  layer  only,  prefix  height  value 
with  an  E  (e.g.  E  12  BKN). 

15.  Print  out  cloud  observation. 

16.  Recycle  program  every  4  minutes. 


CLUSTER  SUPPLEMENT 


Independently  for  each  cellometer: 

1.  Collect  the  cloud  height  as  given  by  each  ceilometer  mea¬ 
surement. 

2.  Order  all  the  cloud  heights  in  ascending  order. 

3*.  Compute  the  least  square  distance  between  any  two  heights 
by 

0  -  (N(J)*N(K)/(NQ)+N(K))*(H(J).H(K)) 

where;  D  ■  Least  square  distance 

N(J)  ■  Number  of  readings  in  the  first  cluster 

N(K)  ■  Number  of  readings  in  the  cluster  im¬ 
mediately  following 

H(J)  ■  Computed  mean  height  for  cluster  (J) 
H(K)  ■  Computed  mean  height  for  cluster  (K) 
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4.  Combine  the  pair  of  clusters  that  have  the  least  squared 
distance  by 

H(J)  -  (N(J)*H(J)  ♦  N(K)*H(K))/(N(J)  ♦  N(K)) 
where  variables  are  as  defined  in  Step  3. 

5.  Compute  pooled  standard  variance  by  P2  *  P2  +  0  /(N-1) 
where : 

*P2  ®  Pooled  standard  variance 

N  «  Number  of  cloud  heights  measured 
in  Step  1. 

6.  Move  all  clusters  down  1  position  starting  from  H{K+1) 

i.e.  H(K)  «=  H(K+1)  and  N(K)  -  N(K+1). 

7.  Repeat  Steps  3  thru  6  until  only  5  clusters  remain. 

8.  Repeat  Steps  3  thru  6  until  only  1  cluster  remains  or  when 
square  root  of  P2  i,s  greater  than  3  times  the  value  of  the 
square  root  of  P2  at  5  clusters. 

9.  The  total  number  of  clusters  is  the  number  remaining  when 
Step  8  Is  true. 


*  The  first  time  thru  this  routine  N(J)  and  N(K)  are  equal  to  1. 


P2  Is  Initlallied  to  0. 
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VISIBILITY  ALGORITHM  (SINGLE  SENSOR) 
T&EO  REPORT  No.  5-80 
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TEST  a  EVALUATION  DIVISION  REPORT  NO. 


SINGLE  SENSOR  VISIBILITY  ALGORITIM 
CONTINUOUS  DISPLAY  MODE 


SECTION  A 
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Introduction 


Visibility  Is  the  most  difficult  of  the  subjective  observation  parameters 
to  automate  since  It  is  the  attempt  to  logically  define  a  human's  persona} 
visual  Impressions.  However,  by  using  the  technique  of  "sensor  equivalent 
visibility"  (SEV),  developed  by  George  and  Leflcowltz  (1972),  we  have  been 
able,  by  processing  measurements  from  a  network  of  sensors,  to  produce  a  sub¬ 
stitute  for  human  visibility. 

SEV  Is  defined  as  any  equivalent  of  human  visibility  derived  from  Instru¬ 
mental  measurements.  In  practice,  the  sensor  from  which  SEV  Is  derived  almost 
always  requires  uniform  visibility  for  an  accurate  calibration.  Once  a  sensor 
Is  calibrated  under  uniform  visibility  conditions.  It  can  then  be  used  to 
determine  visibility  under  nonuniform  conditions.  The  processing  strategies 
for  using  the  SEV's  from  Individual  or  multiple  sensors  to  approximate  human 
visibility  under  nonuniform  visibility  conditions  were  the  subject  of  Aviation 
AutA<iiated  Observation  System  (AV-AWOS)  experiments  (NOAA/Natlonal  Weather 
Service,  1979). 

Federal  Meteorological  Handbook  #1  (FMH  #1)  (NOAA/Natlonal  Weather  Service, 
1979)  specifies  the  manner  In  which  human  observations  of  visibility  are  to  be 
taken  and  reported.  It  defines  prevailing  visibility  (PV)  as,  "The  greatest 
visibility  equaled  or  exceeded  throughout  at  least  half  of  the  horizon  circle 
which  need  not  necessarily  be  continuous."  PV  Is  determined  at  the  usual  slte(s) 
of  observation  or  from  the  control  tower  level  during  low  visibility  conditions. 

SEV  and  PV  have  different  principles  of  observation.  SEV  Is  based  on  sen¬ 
sor  measurement  of  a  small  volume  sample  with  extrapolation  to  overall  areal 
visibility.  PV,  as  determined  by  a  human,  relies  on  sensory  Information  ob¬ 
tained  over  a  relatively  extensive  area.  SEV,  based  on  a  point  sensor,  usually 
has  strongest  relationships  with  PV  during  homogeneous  conditions.  However, 
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is  sufficiently  strong  correlation  in  periods  of  nonunifom  conditions 
rrant  substituting  instrunental  visibility  for  human  visibility, 
rhis  algorithm  is  based  upon  the  visibility  algorithm  developed  during 
/-AUDS  experiment.  The  underlying  assxmption  was  that  while  a  vast  net- 
>f  (point)  visibility  sensors  would  be  needed  to  perfectly  replicate  the 
icrlbed  by  the  human  observer,  a  smaller  network  could  give  an  adequate 
Lptlon.  From  the  results  of  the  AV-AWOS  experiment,  we  have  specified 
le  general  site  configuration  a  three  sensor  network  with  PV  defined  as 
mtral  value  of  this  three  sensor  visibility  network, 
rhe  AV-AWOS  experiments  also  showed  that  there  was  close  agreement,  in 
:ases,  among  the  output  visibilities  from  each  of  the  three  sensor  sites, 
result,  the  PAMOS  cosmittee  has  recommended  that  for  an  automated  system 
iflnltion  of  PV  be  changed  to:  "That  horizontal  visibility  near  the 
's  surface  representative  of  the  visibility  conditions  in  the  vicinity  of 
>lnt  of  observation  or  measurement;  (Eggert,  1980),  and  that  the  current 
Ltlon  of  PV  be  the  method  or  procedure  used  by  the  human  observer  to  pro- 
lis  visual  observation. 

Fslng  the  new  definition  of  PV  we  are  now  able  to  determine,  after  an 
[dual  site  survey,  whether  one  visibility  sensor  can  adequately  describe 
r  any  particular  site.  Our  experiences  at  Dulles  International  Airport 
and  Patrick  Henry  International  Airport  (PHF)  have  pointed  up  the  need 
Lte  surveys  before  installing  sensor  networks  at  airports.  The  primary 
le  of  a  detailed  site  survey  is  to  identify  unique  conditions  that  might 
nice  judgments  on  the  nuisber  of  sensors  needed  and  configuration. 

Fe  have  produced  three  options  of  our  visibility  algorithm: 
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Option  1 


Option  2 


Option  3 


Single  sensor  visibility  algorithm,  continuous  display  mode. 

This  algorithm  Is  the  single  sensor  AV-AWOS  algorithm 
designed  to  be  updated  each  minute  on  the  various  dis¬ 
plays  and  has  the  capability  of  detecting  and  reporting 
Special  Observations. 

Three  sensor  visibility  algorithm,  continuous  display  mode. 

This  algorithm  Is  the  same  as  Option  1  but  uses  three 
sensors  to  determine  prevailing  visibility. 

This  algorithm  also  computes  a  new  visibility  value  each 
minute  but  only  displays  a  new  value  on  demand.  There 
are  no  provisions  for  Specials,  and  the  algorithm  pro¬ 
vides  for  only  one  remark  of  variable  visibility.  This 
option  Is  similar  to  the  current  AUTOB  operation. 


The  enclosed  algorithm  Is  for  the  single  sensor  continuous  display  mode 
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SINGLE  SENSOR  VISIBILITY  ALGORITHM 
(Continuous  Display  Mode) 


SAMPLE  SENSOR 
FOR  10  MINUTES 


LINEAR  AVERAGE 
OVER  10  MINUTES 


SEPARATE 

DAY/NIGHT  CALIBRATIONS 


PREVAILING  VISIBILITY 


STANDARD  AVIATION  FORMAL 
LIMITED  REMARKS 


EACH  MINUTE,  FUG  SPECIALS 


1.  visibility 

Th«  systea  shall  Include  provisions  for  dateralng  a  raprasantativa  visi¬ 
bility  for  a  salected  area.  The  reportable  visibility  values  vlll  range  froa 
1/4  alias  to  84*  allea.  The  output  visibility  Is  called  sensor  prevailing  visi¬ 
bility  (PV)  and  Is  assuaed  to  be  that  horizontal  visibility  near  the  earth's 
surface  representative  of  visibility  conditions  in  the  vicinity  of  the  point 
of  Bsasdreaent. 

1.1  Resolution 

Visibility  sensors  shall  determine  visibility  froa  “less  than  1/4  alia” 
up  to  a  range  of  84*  allies.  Visibility  of  less  than  1/4  mile  Is  reported  as 
0  visibility  while  visibility  greater  than  7.5  miles  Is  reported  as  84-  alias. 

1.2  Significant  Changes  In  Visibility 

The  system  shall  provide  for  detersdnlng  and  reporting  when  prevailing 
visibility  (rounded  to  reportable  values),  decreases  to  less  than,  or  If 
below.  Increases  to  equal  or  exceed: 

1.  3  alios. 

2.  2  alles. 

3.  1  1/2  alles. 

4.  1  mile. 

5.  All  nationally  published  minima,  applicable  to  the  airport, 
listed  in  the  National  Ocean  Survey  Instruaant  approach 
procedure  charts  or  DOD  flips. 

6.  Values  established  locally  because  of  their  significance  to 
local  aircraft  operations. 

7.  Op  to  a  total  of  throe  additional  values  will  be  allowed  for 
conditions  5  snd/or6. 

1.3  No^er  of  Sensors 

One  sensor  is  used  In  the  determination  of  prevailing  visibility.  Loca¬ 


tion  of  this  sensor  will  be  deteralned  by  a  site  survey.  A  day/nlght  sense 
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switch  is  also  required.  This  sense  switch  is  used  to  determine  whether  the 
extinction  coefficient  is  to  be  translated  to  a  day  or  night  visibility  curve. 
1.4  Visibility  Algorithm 

The  visibility  algorithm  shall  perform  the  following  functions  each  minute 
*c  Data  Collection 

a)  Get  one  value  of  extinction  coefficient  from  the  sensor.  Sensor 
data  may  be  preprocessed  if  necessary  to  comply  with  hardware 
specifications  (Appendix  I). 

b)  A  check  shall  be  made  to  determine  if  a  reading  is  outside  sensor 
limits.  If  80,  the  value  is  bad  and  the  previous  good  value  shall 
be  inserted  for  up  to  two  consecutive  times.  The  third  consecutive 
time  use  of  the  bad  sensor  shall  be  discontinued  and  suitable 
notification  made. 

c)  Check  to  see  if  the  day  or  night  sense  switch  should  be  set. 

*c  Convert  to  Sensor  Equivalent  Visibility  (SEV) 

d)  Convert  each  one  minute  value  of  extinction  coefficient  directly  to 
SEV  in  miles  using  separate  conversion  equations  (as  given  in  Appendix 
II)  for  day  and  nighttime  conditions.  (The  day /night  sense  switch 
shall  be  read  each  minute).  If  SEV  is  less  than  0.25  miles,  store 
0.0  for  the  value.  If  SEV  is  more  than  7.5  miles,  store  8.0  for 

the  value. 

*c  Data  Storage 

e)  Store  up  to  10  minutes  of  values  from  the  sensor:  i.e. .  10  values 
of  SEV. 

f)  If  less  than  10  values  are  stores  from  the  sensor,  a  visibility 
estimated  message  shall  be  generated. 

g)  After  10  values  have  been  collected  from  the  sensor,  the  new  value 
received  shall  replace  the  oldest  value  stored. 

*c  Sensor  Averaging 

h)  The  collected  values  obtained  from  Section  f  or  g  above  shall  be 
linearly  averaged  and  rounded  to  the  nearest  reportable  value  as 
given  below.  (Where  8+  Is  any  value  greater  than  7.5). 

*c  Reportable  Visibility  Values 

1)  Any  visibility  must  be  reported  In  the  following  values  (statute 
miles) : 


*c  Indicates  conmients. 


B-9 


0.  1/4,  5/16,  i/8.  1/2, 

1  3/8,  1  1/2,  1  5/3,  1  3/4, 
3,  4,  5,  6,  7  and  8+. 


4  7/8,  1,  1  1/8,  1  1/4, 
//8,  2,  2  1/4,  2  1/2,  2  3/4 


Report  of  PV 


J)  The  values  from  Section  h  when  converted  to  a  reportable  value, 
as  given  In  1  above,  shall  be  considered  the  updated  or  current 
FV  unless  modified  by  k  below. 

Reporting  Low  Visibilities 

k)  If  the  reportable  value  of  PV  as  obtained  from  Section  j  Is  3 
miles  or  less,  use  the  following  procedure:  If  the  updated  PV 
from  Section  J  has  not  changed  by  at  least  two  reportable  values 
from  the  previously  reported  PV,  continue  to  use  the  previous  PV 
as  the  current  PV  for  use  In  any  output  message. 

Variability  Check 

l)  If  the  value  of  PV  as  given  In  Section  J  or  k  above  Is  less  than 
3  miles,  a  variability  check  shall  be  made  using  the  following 
criteria: 

1.  Get  the  last  10  minutes  worth  of  SEV  values  from 
Section  d  above. 

2.  Compare  each  value  with  Its  preceedlng  SEV. 


3.  If  |SEV^  ■>  SEV^^^  I  Is  greater  than  0.5  miles. 
Increment  a  counter. 

4.  When  using  all  ten  comparisons.  If  the  counter  Is 
equal  to  or  greater  than  three;  report  visibility 
as  variable. 

5.  Output  a  remark  that  the  visibility  Is  variable 
followed  by  the  mawliwim  and  minimum  SEV  values 
generated  In  the  last  10  sdnutes  and  rounded  to 
the  nearest  reportable  value.  The  remark  must  be 
of  the  following  form: 


VSBY 


Min  Value 


Max  Value 


Example:  VSBT  1/4V1 


Output  Message 


m)  The  current  PV  will  be  reported  In  the  vlalblllty  section  of  the 
Service  "A"  message  or  any  other  display. 


*c  Indicates  comments. 
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n)  Remarks,  as  generated,  will  be  placed  at  the  end  of  the  Service 
"A"  message  or  any  other  display. 

*c  Special  Message  Requirements 

o)  A  check  shall  be  made  to  determine'  If  a  special  message  Is  re¬ 
quired  by  using  the  following  criteria: 

If  the  current  PV  obtained  from  Section  J  or  k  (when 
compared  to  the  last  Service  “A”  visibility)  meets 
any  of  the  criteria  listed  In  Section  1.2,  a  special 
Service  "A"  message  must  be  generated. 

*c  Update  Frequency 

p)  A  new  visibility  observation  shall  be  generated  each  minute. 


*c  Indicates  comments. 
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APPENDIX  C 


ALWOS  SIX-MONTH  TEST  PLAN  FOR  DULLES  AIRPORT 


Last  Revision:  11/10/80 


Oepartment  of  Transportation 
Federal  Aviation  Administration 


Automated  Low-Cost  Weather  Observation  System  Test  Plan 
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ALKCS  Test  Plan 
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4.0  Test  Data  Collection 

4.1  ALWOS  Data  Records  (Cassette) 

4.2  NWS  .(Silver  Spring,  MO)  Data  Storage 

4.3  Survey  (Opinion)  Sheet 

4.4  WSO,  SAs,  and  SPs 

4.5  Recording  Times 

4.6  Preventive  Maintenance 
5.0  Data  Analysis 

5.1  Comparison  Criteria 

5.2  Controller  Questionnaire  Evaluation 

5.3  Final  Report 

5.4  Listing  of  Computer  Algorithms 
Appendix  A  Visibility  Algorithm 
Appendix  B  Ceiling  Algorithm 
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1.0  PURPOSE 


The  purpose  of  this  test  Is  to  evaluate  the  performance  of  the  Automated 
Low-Cost  Weather  Observation  System  (ALUOS)  developed  by  the  NWS  for  the 
FAA.  The,  tests  are  designed  to  evaluate  the  overall  system  performance 
as  well  as  that  of  the  s'nsors,  field  electronics,  processors,  voice  unit 
displays,  and  any  other  system  component  deemed  important  to  system 
operation.  The  results  of  the  six  (6)  month  ALWOS  evaluation  will  be 
summarized  in  a  final  report. 

2.0  SYSTEM  DESCRIPTION 

The  ALWOS  system  is  shown  in  a  simplified  block  diagram  form  in  Figure 
1.  It  consists  of  a  complement  of  weather  sensors,  interface 
electronics,  processors,  display  and  keyboard.  The  processed  data  is 
also  output  in  audio  form  using  a  voice  synthesizer  operating  under 
microprocessor  control.  The  speech  is  composed  from  a  vocabulary  stored 
in  the  processing  memory. 

The  system  als'  provide!  a  communications  output  which  can  be  utilized  at 
a  remote  site  .o  log  the  data  and  note  system  status. 

2.1  Sensors;  Characteristics  and  Related  Processing 

Described  below  are  the  types  of  sensors,  sensor  outputs,  accuracy  of 
data,  scaling  of  data  on  the  interface  card,  the  processing  of  dat* 
obtained  from  the  interface  card,  quality  control  procedures,  and  output 
processing.  Before  installation,  all  sensors  will  be  calibrated.  They 
will  be  checked  periodically  for  accuracy  in  accordance  with  National 
Weather  Service  routines.  (A  synchronous  motor  shall  be  used  to 
calibrate  and  check  the  anemometer;  a  sling  psychrometer  for  temperature 
and  dew  point). 

2.1.1  Visibility  Meter 

Type:  E6&G  Model  207  Forward  Scatter  Meter 

Type  of  Input  to  Interface  Card:  Analog  voltage  proportional  to  the 
positive  and  negative  iog  of  extinction  coefficient,  (0-5v) 

Accuracy  of  Data: 

Plus  or  minus  0.25  miles  at  one  mile 
Plus  or  minus  0.5  miles  at  three  miles 
Plus  or  minus  1.25  miles  at  five  miles 
Plus  or  minus  3.2  miles  at  eight  miles 

Processing  Applied  to  Data  on  Interface  Card: 

Convert  analog  to  digital  output 
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Processing  Applied  to  Data  from  Interface  Card: 

The  digital  values  are  proportional  to  the  log  of  the  Extinction 
Coefficient  and  are  sampled  once  per  10  seconds,  converted  into 
servsor  equivalent  visibility  values  and  formed  into  a  10-minute 
running  average. 

The  Day/Night  formulas  for  converting  Extinction  coefficients  to 
visibilities  is  Vtr=2.90  (day)  and  .00336V*e‘<^V  (night)  where  V  = 
visibility  in  miles  and  (T  *  extinction  Coefficient  in  miles. 

The  output  values  actually  provided,  once  per  minute,  are: 

0.  1/4,  5/16,  3/8,  1/2,  5/8,  3/4,  7/8,  1,  1  1/8,  1  1/4,  1  3/8, 

1  1/2,  1  5/8,  1  3/4,  1  7/8,  2.  2  1/4,  2  1/2,  2  3/4,  3,  4,  5,  6,  7, 
or  8+  miles.  The  Model  207 -LC  Laboratory  Calibrator  will  be  used 
frequently  to  verify  the  calibration  of  the  visibility  meter. 

'.1.2  Wind  Speed  Sensor 

(Cup  Driven  Tachometer) 

Type  of  Input  to  Interface  Card: 

Continuously  varying  analog  voltage  (0-5v),  lOmv/kt. 

Accuracy  of  Above  Data: 

Plus  or  minus  2  knots  or  5  percent  (whichever  is  greater) 

Processing  Applied  to  Data  on  Interface  Card: 

The  analog  voltage  is  converted  to  digital  output  once  every  second 
(eight  bits) 

Processing  Applied  to  Data  from  Interface  Card: 

The  central  processor  receives  the  eight  bits  of  digital  data  once 
every  second  and  averages  60  1-second  values  for  a  1-minute 
arithmetic  average.  This  average  is  then  scaled  and  converted  to 
knots.  This  data  is  then  placed  in  the  output  buffer. 

Quality  Control  Applied: 

Every  second  each  data  is  checked  against  a  maximum  and  minimum 
value  before  it  is  processed  Into  the  averaging  part  of  the 
program.  If  either  maximum  or  minimum  values  are  exceeded,  then  a 
missing  character  is  placed  into  the  output  buffer. 

Optional  Output  Criteria:  ' 

1)  Peak  winds,  gusts:  During  every  mi .»ute,  every  1-second  value  is 
examined  for  the  peak  value.  This  1-minute  peak  value  is  then 
stored  in  a  push  down  store  for  the  last  lO-minute  values.  This 
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lest  10-minute  storage  is  examined  once  every  minute  to  determine  the 
highest  value.  If  this  value  is  equal  to  or  greater  than  14  knots  and  is 
greater  than,  or  equal  to  the  present  1-minute  average  plus  5  knots,  then 
this  value  is  used  to  represent  the  last  10-minute  peak  gust  wind  speed. 
If  this  value  does  not  exceed  the  previous  conditions,  then  two  zeros  are 
placed  into  the  output  buffer. 

2)  Calm:  If  the  1-minute  running  average  wind  speed  is  2  knots  or 
less,  then  whatever  is  in  the  output  buffer  for  wind  speed  and 
direction  is  replaced  by  zeros  and  the  voice  output  reports  the 
winds  as  "calm”. 

Tests  Applied: 

In  every  message  frame  a  test  signal  is  applied  to  the  interface 
card  to  check  the  calibration  of  the  converter.  If  it  does  not 
verify  then  a  missing  indication  is  placed  into  the  output  buffer, 
and  the  processor  keeps  on  trying  to  verify. 

2.1.3  Wind  Direction  Sensor 

(Vane  Driven  Potentiometer  With  Three  Taps) 

Type  of  Input  to  Interface  Card: 

Continuously  varying  analog  voltage  buffered  by  operational 
amplifiers 

Accuracy  of  Sensor: 

Ten  degrees  RKS  (0-360  degrees) 

Processing  Applied  to  Data  from  Interface  Card: 

The  central  processor  receives  the  eight  bits  of  digital  data  once 
every  second  and  averages  this  data  exponentially  to  an  equivalent 
of  a  1-minute  running  average.  This  average  is  then  scaled  and 
converted  to  an  output  representing  wind  direction  to  the  nearest  10 
degrees  of  magnetic  north  for  the  voice  output  and  true  north  for 
the  displays.  When  the  wind  direction  is  from  the  north,  360  is 
used  rather  than  zero  as  the  wind  direction.  When  the  wind  speed  is 
2  knots  or  less,  00/00  represents  the  wind  direction  and  speed  on 
the  display  and  "calm"  is  reported  on  the  voice  output. 
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Data  Quality  Control  Applied: 

Tests  Applied: 

A  test  signal  is  applied  to  the  interface  card  to  check  the 
calibration  of  the  converter.  If  it  does  not  verify,  then  a  missing 
indication  is  placed  into  the  output  buffer.  Upon  any  missing 
condition,  the  processor  applies  the  checks  again  and  if  the  output 
verifies,  it  continues  normal  operation.  If  not,  it  will  try  again 
every  second. 

2.1.4  Temperature  and  Dew  Point  Sensors 

Temperature-YSI  Triple  Element  Thermistor. 

Dew  Point-Same  Thermistor  enclosed  within  a  dewcell  bobbin. 

Both  sensors  mounted  in  Gill  aspirated  radiation  shelters. 

Type  of  Input  Into  Card: 

Continuously  varying  resistance  converted  to  analog  voltage  signals 
buffered  by  operational  amplifier,  lOmv/OF. 

Processing  Applied  to  Input  on  The  Interface  Card: 

Data  is  converted  once  every  10  seconds  to  digital  data. 

The  Temperature  Algorithm  is  Eont'-O. 00310638  x  E<«  x 
T+.6924E|n,  Ein«3.219. 

The  Dew  Point  Algorithm  Is  *  ^in  * 

T+.597435Ein,  Ein=2.404. 

Processing  Applied  to  Data  from  Interface  Card: 

The  central  processor  uses  6  of  the  10-second  samples  to  form  the 
1-minute  average  temperature  and  dew  point  every  minute.  This  data 
is  then  pushed  into  a  running  5-m1nute  storage.  Every  minute  the 
5-minute  average  is  determined  and  converted  to  Fahrenheit. 

Quality  Control  Applied: 

Every  new  1-minute  sample  of  the  input  data  is  compared  to  the 
previous  1-minute  average  and,  if  it  varies  by  more  than  plus  or 
minus  six  (6)  degrees  Fahrenheit,  a  "missing"  is  placed  into  the 
output.  Once  every  message  frame  a  test  reference  voltage  is 
applied  to  the  interface  and  if  it  does  not  verify,  a  "missing"  is 
also  placed  into  the  output. 


Tests  Applied: 

Dew  pbint  data  is  not  considered  valid  unless  Its  value  Is  less  than 
or  equal  to  the  temperature  value. 

2.1.5  Impulsphysik  Ceilometer 

Type:  Pulsed  6aAs  Laser 

Range:  100  to  3,000  feet 

Type  of  Input  to  Interface  Card: 

An  ElA  RS-232  voltage  loop,  serial  digit  format,  110  baud, 
asynchronous,  1  Start-2  stop  and  8  bits  of  data.  The 

asynchronous  data  stream  is  issued  once  per  28  seconds  headed  by  an 
STX  character  and  ended  with  an  ETX  character.  In  between  are  63 
bytes,  representing  returns  from  50-foot  range  bins  from  100  feet  to 
3,100  feet.  The  returns  are  binary  encoded  from  00  to  FF  repre¬ 
senting  the  backscattered  energy  received  in  that  range  bin. 

Processing  Applied  to  Input: 

A  dedicated  processor  card  will  Input  the  data,  determine  cloud 
strikes  and  heights,  then  process  the  data  in  accordance  with  Autob 
(automatic  observer)  algorithm  rules.  Cloud  layer  levels  and  sky 
condition  (broken,  scattered  or  overcast)  are  determined  and 
presented  in  the  output.  One  hundred-foot  levels  are  given.  The 
data  is  a  23-minute  running  average  produced  each  4  minutes.  The 
Autob  algorithm  uses  visibility  data  as  an  input.  Quality  checks 
are  available  on  receiver  sensitivity  and  laser  power. 

2.1.6  Pressure  Sensors  (Garrett  AiResearch  No.  2101800 
Quartz,  Capacitive-Plate) 


Type  of  Input  to  Interface  Card: 

Continuously  varying  analog  voltage  0.3387  v/in  Hg,  Ov  «  17.718"Hg, 
4.6v  «  31.3"  Hg 


Accuracy  of  Above  Data: 

Plus  or  minus  0.15X  of  range. 

Worst  case  from  60  KPA  to  100  KPA  where  (.07  KPA  ■  0.7  MB  •  0.02") 

Processing  Applied  to  Data  on  Interface  Card: 

Converts  analog  voltage  once  every  10  seconds  to  digital  output  (12 
bits). 

Elevation  constants  for  altimeter  processing  are  stored  in  a 
progratimable  read  only  memory  (PROM).  Offset  or  calibration 
voltages  for  both  sensors  are  adjusted  on  the  local  input  card  and 
read  into  the  local  A/D  converter  to  correct  the  pressure  readings. 
These  values  are  read  by  the  processor. 

Processing  Applied  to  Data  from  Interface  Card: 

Dual  pressure  sensors,  contained  in  an  oven  and  thermostatically 
controlled  supply  input  data.  The  input  data  are  used  to  form  two 
1-minute  averages  of  "inches  of  mercury".  If  they  vary  by  more  than 
0.04",  then  a  "missing"  is  placed  into  the  output  buffer.  If  the 
difference  is  less  t^an  or  equal  to  0.04"  Hg  then  the  lower  value  of 
the  two  is  used  to  calculate  altimeter  setting. 

Start  Up  Conditions: 

Data  is  not  considered  valid  until  a  25-minute  warm-up  period  has 
taken  place.  The  pressure  data  can  be  displayed  immediately  by 
operation  of  an  override  key. 

Calibration: 

A  recording  barograph  installed  in  close  proximity  to  the  pressure 
sensors  will  continuously  monitor  the  ASI  readings.  Also,  the 
accuracy  of  the  ASI  output  will  be  checked  biweekly  using  a  Wallace 
and  Tiernan  portable  transfer  standard. 

2.1.7  Thunderstorm  Sensors 

Type:  Broad  band  antenna,  detection  of  base  of  return  stroke. 

Manufacturer: 

Atlantic  Scientific 

Type  of  Input  to  Interface  Card: 

Contact  Closure  -  Ov  ■  no  thunderstorms 
5v  ■  thunderstorms 

Processing  Applied  to  Data  from  Interface  Card: 

One-second  sampling  of  thunderstorm  sensor  output 


2.2  Renotlng  Field  Data 

Most  of  the  sensors  are  located  near  the  center  of  the  airport  and  data  obtained 
frea  theo  must  be  digitized  and  transmitted  serially  to  an  equipment  room  where 
the  data  is  processed  by  a  central  processor  which  in  the  ALUCS  system  is  the 
Intel  80/20  cicrocoaputar. 

Analog  infomation  from  sensors  representing  wind  speed,  wind  direction, 
temperature,  dewpoint  and  visibility  enter  a  ccnterfleld  located  enclosure 
where  the  inforcatlon  is  converted  into  digital  form.  Within  the  enclosure 
are  multiplexers,  A/0  converters  send-modems,  a  heater,  blower,  lightning 
arresting  devices,  power  supplies  shut-down  and  tum-on  electronics.  A 
completely  dual  data  handling  system  is  provided. 


The  ALVOS  system  in  its  field  unit  has  the  following  data  in  16  analog  channels: 


Channel  Data 


0  Temperature 

1  Dew  Point 

2  Visibility  (Pos.  Logarithmic) 

3  Visibility  (Neg  Logarithmic) 

4  VJind  Speed 

5  Wind  Direction  A 

6  Wind  Direction  B 

7  Wind  Direction  C 

8  -fS.CV  DC  Reference  to  Wind  Direction  Sensor 

9  +3. 2 19V  DC  Rpferenca  to  Temperature  Thermistor 

10  +2.40AV  DC  Reference  to  Duw  Point  Ther niator 

11  +2.5V  DC  Divided  dovm  from  the  +20V  power  supply 

12  ■♦•2.5  V  L'C  Divided  down  from  the  45V  power  supply 

13  +1.0V  DC  Divided  dov.^i  from  the  4l5V  power  supplies 

14  Heater  (X.  indication  (Yes“+5V) 

15  OV  DC  Ground  P.sfcrenca 


Tills  data  In  each  cl.ann  li  is  represented  in  12 -bit  form  and  identified  by 
four  adJrc.?!'  lirs.  Stxccen  aJJitii'nal  channels  .and  an  additional  identifl  'r 
blc  nrr-  cvailnol."'  but  rot  used  in  the  prcaonc  configuration. 
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The  electronics  In  the  field  unit  are  self  synchronized  (each  channel)  and 
provide  data  serially  to  a  Line  Switch  Modulator  Modem  which  supplies  data  at 
approximately  2720  bits  per  second  over  a  laudllne  that  carries  the  data  to 
the  ALWOS  central  processor  In  the  designated  equipment  room. ae-  Llie  Dulles  ■ 
jluntiul  Tuwri.  The  data  Is  demodulated  by  a  Line  Switch  Demodulator  before 
entering  the  central  processor. 

2.3  LED  Incoming  Data  Display 

The  Incoming  data  from  the  field  unit  is  displayed  on  a  row  of  LED  lights  on  the 
ALWOS  console.  Seventeen  bits  are  shown,  twelve  for  data,  five  for 
Identification  of  t>pe  of  data. 


2.4  Central  Processor 


The  central  processor  accepts  the  demodulated  data  from  the  fieldjpaier,  from 
the  Precipitation,  Thunderstorm,  Day-Night  and  Decal  Barometric  Pressure 
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Sensors.  The  central  processor  also  accepts  data  from  the  ceilometer  processor 
(A  separate  Intel  80/20  microcomputer).  The  Central  Processor  Is  an  8-bit* 
microprocessor  which  performs  all  averaging,  detects  out-of-llmlt  data  and  data 
rates,  and  formats  all  output  data  from  the  voice  unit,  CRT  display  and 
communications  output. 


2.5  Voice  Unit 

The  voice  unit,  a  format,  synthesizer  and  a  prestored  vocabulary  (PROM)  of 
formant  encoded  words  Is  provided  on  a  card  which  Is  manufactured  by  Speech 
Technology  Inc.  of  California. 
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The  voice  unit  is  a  printed  circuit  board  which  plugs  into  the  subrack  with  the 
CP.  It  accepts  data  from  the  Central  Pracessrr.  It  is  directed  to  say  "data  is 
cissing"  wherever  any  sensor  has  out-of-llDit  values,  or  excessive  rates  of 
change  in  values. 

2.6  CRT  Display 

A  CRT  accepts  data  from  the  central  processor  displays  output  data  once  per 
minute.  Since  this  display  also  prints  the  display  of  raw  data  it  is  a  useful 
maintenance/ installation  cool.  It  can  also  be  used  to  demonstrate  the  operation 
of  the  system  to  controllers  and/or  other  evaluator. 

2 . 7  Communication 

The  system  outputs  to  users  the  derived  weather  products  and  the  system  status 
using  a  low-rate  (300  baud)  RS232  communication  link.  This  allows  remote 
display  and  recording  of  the  weather  data  and  initiation  of  corrective 
maintenance  if  required. 


2.1.8  Precipitation  Yes/No  Sensor 


Type:  Resistance  grid. 

Manufacturer: 

Wong  Labs. 

Type  of  Input  to  Interface  Card: 

Ov  *  no  precipitation 
+5v  *  precipitation 

Processing  Applied  to  Data  from  Interface  Card; 

A  1-minute  sampling  of  the  Precipitation  Y/N  Sensor  Output  is 
performed. 

2.1.9  Day /Night 

Manufacturer: 

Precision  Multiple  Controls,  Inc. 

Type  of  Input  to  Interface  Card: 

Ov  *  night 
+5v  ®  day 

This  data  is  supplied  to  the  visibility  routine  i(l)ere  either  the  day 
formula  V(r'»2.90  or  the  night  formula  .00336V«e"*^’*  used. 

3.0  SYSTEM  INSTALLATION  AND  CHECKOUT 
3.1  Installation 


The  system  will  be  installed  at  the  Dulles  International  Airport.  The 
sensors,  consisting  of  Wind  Speed  and  Direction,  Temperature,  Dew  Point, 
Thunderstorm,  Visibility,  Ceiling,  and  the  field  electronics  are 
centrally  located  on  the  airport  in  close  proximity  to  the  Rotating  Beam 
Ceilometer  (RBC)  and  the  operational  transmissometer.  The  dual  pressure 
transducers,  day/night,  and  precipitation  sensors  will  be  located  at  the 
NWS  building  adjacent  to  the  FAA  control  tower.  The  ALWOS  electronics, 
consisting  of  the  processors,  displays,  etc.,  are  located  inside  the  NWS 
building.  A  remote  CRT  and  speaker  with  on/off  switch  will  be  installed 
In  the  Dulles  Tower  complex  for  the  purpose  of  permitting  controllers  and 
maintenance  personnel  to  monitor  and  observe  the  system  output.  The 
system  will  not  be  used  operationally. 

Evaluation  of  the  ALWOS  system  performance  will  require  the  use  of  data, 
taken  from  an  independent  set  of  sensors,  provided  by  the  NWS  Weather 
Service  Office  (WSO)  which  Is  located  near  the  ALWOS  site.  The  WSO 
equipment  consists  of  temperature,  dew  point,  pressure  sensors. 
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and  Rotating  Beam  Cellometer.  When  the  NWS  observer  visibility  is  1  mile 
or  belov',  obtain  transmissometer  trace  for  runway  .  Transmissometer 
data  converted  to  visibility  (as  RVV)  will  be  compared  with  observer  and 
EG&G  visibility  data. 

The  official  NWS  weather  data  as  given  on  the  daily  suninary  sheet  of  SAs 
and  SPs  will  be  used  as  the  standard  for  comparison  with  the  ALUOS  system 
output  data. 

An  ALWOS  remote  display  and  speaker  will  be  located  in  a  room  in  the 
Dulles  Control  Tower  building  for  viewing  and  listening  by  controllers 
and  other  personnel  participating  in  the  system  evaluation. 


3.2  Checkout 


Follovking  the  installation  of  the  ALWOS  system,  the  equipment  shall  be 
tested  using  a  simulated  set  of  sensor  inputs.  Where  analog  inputs  are 
simulated,  the  voltage  source  shall  be  capable  of  supplying  0-5v  to  a 
resolution  of  ♦  1  mv.  A  digital  voltmeter  shall  be  used  to  check  the 
accuracy  of  the  voltage  settings.  Digital  inputs  shall  be  simulated 
using  a  microprocessor,  or  a  similar  digital  device. 

Based  on  the  known  simulated  inputs  applied  to  ALWOS  processors,  the 
processed  output  shall  agree  with  the  input  to  the  following  tolerances: 


Wind  Speed 
Wind  Direction 
Wind  Gusts 
Temperature 
Dew  Point 
Altimeter  Setting 
Visibility 

Ceiling 


To  nearest  2  Kts 

To  nearest  lOO 

To  nearest  2  Kts 

To  nearest  PF 

To  nearest  PF 

To  nearest  0.02'’Hg 

To  nearest  1/16  of  a  mile  or  more 

depending  on  range 

To  nearest  100  Ft. 


The  simulated  inputs  shall  also  be  used  to  check  the  system  failure 
detection,  algorithms,  display  and  voice  outputs,  and  the  recordings  of 
the  output  products. 


4.0  TEST  DATA  COLLECTION 

Test  Data  will  be  collected  at  Dulles  International  Airport  during  the 
6-month  demonstration  period. 


4.1  ALWOS  Data  Recorder  (Cassette) 


The  processed  sensor  data  are  recorded  on  a  Techtran  Cassette  Recorder 
once  ever^  20  minutes.  The  data  are  presented  serially,  in  ASCII  format, 
at  300  baud  and  RS-232  levels.  A  Status  (or  Maintenance)  word  Is  also 
recorded.  The  Maintenance  word  bits  and  types  of  failures  are  shown 
below. 

Bit  Type  of  Failed  Device 

0  Temperature 

1  Dew  Point 

2  Wind  Speed 

3  Wind  Direction 

4  Pressure  #1 

5  Pressure  #2 

6  Pressure  Calibration  (a  voltage  check) 

7  Visibility 

e  Internal  A/D  (Intel  SBC  711) 

9  Remote  A/D  #1 

10  Remote  A/D  #2 

11  Unused 

12  Unused 

13  Unused 

14  Unused 

15  Unused 

The  bits  are  encoded  as  nunrt)ers  from  0  to  2047. 

Also  recorded  are  ASCII  symbols  for  carriage  return,  line  feed,  etc.,  so 
that  the  tape  recorder  output  may  be  fed  into  a  Silent  700  Printer  and 
formatted  into  a  clearly  understandable  printed  page  of  data. 
Approximately  50  bytes  make  up  a  message  frame. 

4.2  NWS  (Silver  Spring)  Data  Storage 

A  telephone  line  from  Dulles  International  Airport  will  be  used  to  remote 
data  to  the  NWS  Equipment  Development  Laboratory.  The  data  may  be 
archived  on  a  disk,  and/or  displayed  on  a  CRT  display,  or  printed.  The 
data  transfer  rate  will  be  300  baud. 


4.3  Opinion  Sheet 

An  opinion  sheet  will  be  distributed  for  obtaining  impressions  from 
controllers  and  other  subjects  who  will  be  asked  to  evaluate  the  ALWOS 
system.  The  questions  will  be  directed  toward  evaluating  the 
Intelligibility  of  vocal  and  displayed  messages. 

A  sample  Opinion  Sheet  is  shown  below. 
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I  :  SURVEY  (OPINION)  SHEET 

I  DULLES  AUTOMATED  LOW-COST  WEATHER  OBSERVATION  SYSTEM  (ALWOS) 

!  1.  VOICE  QUALITY;  YES  NO 

:  a.  Did  you  have  difficulty  understanding  a  particular 

word  or  phrase?  _  _ 

b.  If  yes  to  above  question,  please  identify: 

i - 


a.  AAT  _ 

b .  AAF  _ 

c.  OTHER  _ 

Thank  you  for  your  help.  If  you  have  wy  questions,  or  If  you  would  like 
more  information  on  the  system,  please  write  or  call: 

David  Floyd  or  John  Dorman  >  Washington  Headquarters: 
(202)426-8427 

Federal  Aviation  Administration 
ARD-412 

400  -  7th  Street.  SW 
Washington,  DC  20590 


L. 
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4.4  WSO  SAs  and  SPs 


The  daily  surmaries  of  hourly  surface  observations,  SAs,  or  Specials, 

SPs,  taken  at  the  Dulles  Weather  Service  Office  (WSO)  will  be  collected 
and  used*  as  standards  for  comparison  with  the  output  of  the  ALWOS  system. 

The  values  to  be  obtained  from  the  official  NWS  SAs  and  SPs  are  time, 
sky,  ceiling,  visibility,  temperature,  dew  point,  wind  speed  and 
direction,  gust,  and  altimeter  setting. 

4.5  Recording  Times 

The  ALWOS  Data  Recorder  will  record  approximately  50  bytes  of  data  every 
20  minutes. 

Remote  recording  at  the  NWS  Equipment  Development  Laboratory  may  also  be 
performed  at  the  same  rate. 

4.6  Preventive  Maintenance 

To  discover  trends  in  the  operation  of  the  ALWOS  and  its  sensors  in  a 
timely  manner,  a  qualified  weather  observer  or  technician  shall  visit  the 
site  every  Monday,  Wednesday,  and  Friday,  and  shall  have  available 
readings  for  the  last  period.  He  shall  compare  the  last  readings 
obtained  by  ALWOS  to  those  obtained  by  the  NWS  observer  at  the  WSO.  If 
he  discovers  that  the  system  output  data,  in  whole  or  in  part,  does  not 
agree  with  the  official  weather,  he  should  perform,  or  cause  to  be 
performed,  one  or  all  of  the  following  tests  as  needed: 

1.  Run  diagnostics  on  the  computer  (if  available). 

2.  Simulate  inputs  and  observe  outputs. 

3.  Check  individual  outputs  of  sensors. 

4.  Use  checkout  procedures  and  tolerances  shown  in  Section  3.2. 

5.0  DATA  ANALYSIS 

5.1  Comparison  Criteria 

The  SAs  and  SPs  will  be  compared  with  the  output  of  the  ALWOS  system. 
Since  the  sensors  differ  in  their  locations  they  can  be  expected  to  show 
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different  results.  The  following  list  of  parameters  and  their  tolerances 
shall  be  used  as  a  basis  for  comparison.  The  comparison  will  be  done 
every  other  day  (Monday,  Wednesday,  Friday).  Any  discrepancies  between 
the  observations  will  be  noted  in  a  log  book  which  will  be  kept  at  the 
ALWOS  location. 

The  list  of  parameters  or  comparison  is  an  initial  list  to  be  used  for 
early  comparisons.  The  values  given  show  an  attempt  to  take  into 
cons ’de-at ion  the  distance  factor  between  the  two  sets  of  sensors.  After 
a  few  '.■.eeks  of  testing  and  observation  of  phenomena  due  to  siting,  the 
comparison  parameters  may  have  to  be  tightened  or  opened  in  some  of  the 
readings. 


COMPARHuN  OF  ALWOS  AND  NWS  DATA 
TOLERANCES 


Wind  Direction 

Wind  Speed 
Temperature 
Dew  Point 
Visibility 

Ceil’ng  Height  & 
Sky  Condition 

Altimeter 


+  300  5  to  20  KTS 
+  200  20  KTS  &  up 

+  5  KTS 

+  30  F 

+  50  F 

1/4  mile  1/4  -  3  miles 
1  mile  3-8  miles 

500  Ft.  and  exact 
descriptor 

.04"  Hg 


Precipitation 

Thunderstorm  Exact  descriptor 
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5.2  Controller  Questionnaire  Evaluation 

The  intelligibility  of  the  ALWOS  messages  will  be  resolved  from  the 
questionnaire.  The  voice  quality  will  be  also  determined  from  their 
responses. 

Only  a  rough  measure  of  voice  quality  and  intelligibility  will  be 
obtained  by  querying  the  controllers.  The  Voice  Unit  can  be  tested  in  a 
stand  alone  test  with  standard  tests  such  as  Diagnostic  Rhyme  Tests, 
which  are  designed  to  obtain  measures  of  intelligibility  and  voice 
quality.  Usually,  the  manufacturer  of  the  Voice  Unit  has  previous 
records  of  such  tests.  These  should  be  obtained  from  the  manufacturer  or 
from  Federal  Agencies  such  as  the  Air  Force  Electronics  Systems  Division 
who  make  these  tests,  if  possible. 

Since  the  ALWOS  vocabulary  does  not  contain  the  standard  word  test  set, 
the  quality  of  the  ALWOS  speech  will  be  evaluated  based  on  recognition  of 
the  message  and  any  specific  words  which  apply  to  the  standard  test  set. 

5.3  Final  Report 

A  final  report  will  be  written  which  will  analyze  all  of  the  instances 
where  the  ALWOS  system  outputs  varied  excessively,  i.e.,  beyond  the 
tolerances  given  in  Section  5.1.  Statistics  will  be  provided,  giving  the 
frequency  that  a  particular  weather  parameter  was  "out  of  tolerance." 
Explanations  will  be  offered  for  those  "out  of  tolerance"  cases  when  they 
can  be  found.  For  example,  the  time  that  hourly  surface  observations  are 
made  vary  by  several  minutes,  from  hour  to  hour.  Thus,  the  ALWOS  data 
may  be  for  times  several  minutes  removed  from  the  hourly  surface 
observations. 

In  addition,  the  report  shall  list  all  ALWOS  sensor  or  equipment  failures 
when  they  occurred,  under  what  conditions,  and  what  was  the  probable 
cause.  The  hourly  surface  observations  and  the  ALWOS  printouts  during 
the  period  of  evaluation  will  be  preserved  as  an  appendix  to  the  final 
report . 
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